2ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

ネットワークプログラミング相談室 Port28

1 :デフォルトの名無しさん:2012/04/18(水) 17:15:34.85
主にソケットに関しての質疑応答スレッドです。

Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

関連リンクは>>2-10辺り
足りなかったら適当に付け足してね

前スレ
ネットワークプログラミング相談室 Port26
http://hibari.2ch.net/test/read.cgi/tech/1269343909/
関連スレ
ネットワークプログラミング雑談
http://hibari.2ch.net/test/read.cgi/tech/1235800707/
Java ネットワークプログラミング 【教えて!】
http://hibari.2ch.net/test/read.cgi/tech/1086238859/

2 :デフォルトの名無しさん:2012/04/18(水) 17:16:02.36
過去スレ:
Port27 ttp://toro.2ch.net/test/read.cgi/tech/1293284816/
Port26 ttp://hibari.2ch.net/test/read.cgi/tech/1269343909/
Port25 ttp://pc12.2ch.net/test/read.cgi/tech/1255459388/
Port24 ttp://pc12.2ch.net/test/read.cgi/tech/1246895188/
Port23 ttp://pc12.2ch.net/test/read.cgi/tech/1230466044/
Port22 ttp://pc11.2ch.net/test/read.cgi/tech/1222603744/
Port21 ttp://pc11.2ch.net/test/read.cgi/tech/1204287577/
Port20 ttp://pc11.2ch.net/test/read.cgi/tech/1186418855/
Port19 ttp://pc10.2ch.net/test/read.cgi/tech/1159692799/
Port18 ttp://pc11.2ch.net/test/read.cgi/tech/1171029896/
Port17 ttp://pc8.2ch.net/test/read.cgi/tech/1148944560/
Port16 ttp://pc8.2ch.net/test/read.cgi/tech/1136005644/
Port15 ttp://pc8.2ch.net/test/read.cgi/tech/1128088448/
Port14 ttp://pc8.2ch.net/test/read.cgi/tech/1118469143/
Port13 ttp://pc8.2ch.net/test/read.cgi/tech/1109793931/
Port12 ttp://pc5.2ch.net/test/read.cgi/tech/1102427855/
Port11 ttp://pc5.2ch.net/test/read.cgi/tech/1096187183/
Port10 ttp://pc5.2ch.net/test/read.cgi/tech/1090385857/
Port9 ttp://pc5.2ch.net/test/read.cgi/tech/1080658835/
Port8 ttp://pc5.2ch.net/test/read.cgi/tech/1073560271/
Port7 ttp://pc5.2ch.net/test/read.cgi/tech/1063035045/ ★行方不明
Port6 http://pc5.2ch.net/tech/kako/1052/10521/1052106444.html
Port5 http://pc2.2ch.net/tech/kako/1040/10402/1040220302.html
Port4 http://pc3.2ch.net/tech/kako/1034/10342/1034236536.html
Port3 http://pc3.2ch.net/tech/kako/1023/10233/1023359282.html
Port2 http://pc.2ch.net/tech/kako/1006/10062/1006258198.html
Port1 http://pc.2ch.net/tech/kako/970/970344582.html

3 :デフォルトの名無しさん:2012/04/18(水) 17:16:24.06
図書コーナー:
UNIXネットワークプログラミング〈Vol.1〉ネットワークAPI:ソケットとXTI
 http://www.amazon.co.jp/exec/obidos/ASIN/4894712059/
 そのソースコード
 http://www.unpbook.com/src.html
詳解TCP/IP〈Vol.1〉プロトコル
 http://www.amazon.co.jp/exec/obidos/ASIN/4894713209/
詳解TCP/IP〈Vol.2〉実装
 http://www.amazon.co.jp/exec/obidos/ASIN/4894714957/
詳解TCP/IP〈Vol.3〉トランザクションTCP, HTTP, NNTP, UNIXドメインプロトコル
 http://www.amazon.co.jp/exec/obidos/ASIN/4894716674/
TCP/IPによるネットワーク構築
 〈Vol.1〉原理・プロトコル・アーキテクチャ
  http://www.amazon.co.jp/exec/obidos/ASIN/432012054X/
 〈Vol.3〉クライアント‐サーバプログラミングとアプリケーション
  http://www.amazon.co.jp/exec/obidos/ASIN/4320028007/
  Linux/POSIXソケットバージョン
  http://www.amazon.co.jp/exec/obidos/ASIN/4320120841/
  Windowsソケットバージョン
  http://www.amazon.co.jp/exec/obidos/ASIN/4320029992/

4 :デフォルトの名無しさん:2012/04/18(水) 17:16:40.78
マスタリングTCP/IP RTP編
 http://www.amazon.co.jp/exec/obidos/ASIN/4274065618/
Linuxソケットプログラミング?ネットワークプログラミングにおける実践技法
 http://www.amazon.co.jp/exec/obidos/ASIN/4894714671/
Webプロトコル詳解?HTTP/1.1、Webキャッシング、トラフィック特性分析
 http://www.amazon.co.jp/exec/obidos/ASIN/4894715414/
WinSock2.0プログラミング
 http://www.amazon.co.jp/exec/obidos/ASIN/4797306882/
猫でもわかるネットワークプログラミング
 http://www.amazon.co.jp/exec/obidos/ASIN/4797323604/
IPv6ネットワークプログラミング
 http://www.amazon.co.jp/exec/obidos/ASIN/4756142362/
Visual Basicではじめるネットワークプログラミング超入門
 http://www.amazon.co.jp/exec/obidos/ASIN/4839917523/

5 :デフォルトの名無しさん:2012/04/18(水) 17:16:56.80
URL抜粋:
★規格
RFC 日本語版リスト
 http://www5d.biglobe.ne.jp/~stssk/rfcjlist.html
JPNIC RFC関連リンク集
 http://rfc-jp.nic.ad.jp/link/
RFC Editor
 http://www.rfc-editor.org/
HTMLなRFC (セクションを直に示すのに便利)
 http://www.freesoft.org/CIE/RFC/
RFC 2616 "Hypertext Transfer Protocol -- HTTP/1.1" 日本語訳
 http://www.studyinghttp.net/cgi-bin/rfc.cgi?2616
IANA Well known port numbers
 http://www.iana.org/assignments/port-numbers

6 :デフォルトの名無しさん:2012/04/18(水) 17:17:11.11
★プログラミング
C10K ヘヴィーロードサーバ
 http://www.kegel.com/c10k.html
C10K ヘヴィーロードサーバ(日本語訳)
http://www.hyuki.com/yukiwiki/wiki.cgi?TheC10kProblem
MSDN
 http://msdn.microsoft.com/library/en-us/dnsitehelp/html/tochelp.asp
Raw IP Networking FAQ
 http://www.whitefang.com/rin/
Java で packet capture
 http://netresearch.ics.uci.edu/kfujii/jpcap/doc/
Randomness Recommendations for Security
 http://www.faqs.org/rfcs/rfc1750.html
BoostSocket
 http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostSocket
The Code Project - Internet & Network programming
 http://www.codeproject.com/internet/
ネットワークプログラミングの基礎知識 (問題ありのサイト?)
 http://X68000.q-e-d.net/~68user/net/

7 :デフォルトの名無しさん:2012/04/18(水) 17:17:30.46
★ツール類
ethereal - http://www.ethereal.com/
Wireshark - http://www.wireshark.org/
tcpdump - http://www.tcpdump.org/
Windump - http://netgroup-serv.polito.it/netgroup/tools.html
WinPcap - http://www.winpcap.org/
pathchar - ftp://ftp.ee.lbl.gov/pathchar/
pchar - http://www.employees.org/~bmah/Software/pchar/
Packetyzer - http://www.networkchemistry.com/products/packetyzer/
libevent - http://www.monkey.org/~provos/libevent/

★プロトコル
TTCP
 http://www.sean.de/Solaris/ttcp.html
 http://www.kohala.com/start/ttcp.html
UDP Hole Punching
 http://homepage3.nifty.com/toremoro/p2p/firewall.html

★IP, TCP実装
http://www.iti.fi/documentation/miniip.html
http://www.sics.se/~adam/uip/
http://www.codeguru.com/Cpp/I-N/network/tcpip/article.php/c5447/
http://www.geocities.jp/bruce_teller/security/garakuta.htm

8 :デフォルトの名無しさん:2012/04/18(水) 17:19:53.47
前スレ修正し忘れた。

ネットワークプログラミング相談室 Port27
http://toro.2ch.net/test/read.cgi/tech/1293284816/

9 :デフォルトの名無しさん:2012/04/21(土) 14:33:05.88
VBでパケットキャプチャをするプログラムを作ったんですが
PCによってキャプチャできたりできなかったりします。
ネットワークカードによってキャプチャできないような
ものがあるのでしょうか?

10 :デフォルトの名無しさん:2012/04/21(土) 23:21:30.10
>>9
ワイヤーシャークとかでキャプチャしてみれば自分のプログラムが
おタコなのかどうかわかるだろう。

11 :デフォルトの名無しさん:2012/04/21(土) 23:59:44.90
>>9
いいえ。


12 :デフォルトの名無しさん:2012/04/22(日) 02:44:51.03
>>9
NICの指定と設定が間違ってる

13 :デフォルトの名無しさん:2012/04/27(金) 22:47:04.63
質問があります。

プライベートアドレスは、ifaddrsなどで取得できるのはわかるのですが、
グローバルアドレスの場合は、プログラムからどのように取得すればよいのでしょうか?
ルータにアクセス?して取得する方法があるのでしょうか。。。

14 :デフォルトの名無しさん:2012/04/27(金) 23:42:44.34
確実な方法としては、外部につないでその結果を返すサーバを作り運用する

15 :デフォルトの名無しさん:2012/04/27(金) 23:57:22.15
授業科目案内トップ > 授業科目案内 教養学部 > 専門科目 産業と技術専攻 > ネットワークとサービス('12)http://www.ouj.ac.jp/hp/kamoku/H24/kyouyou/A/sangyo/s_1554581.html

16 :デフォルトの名無しさん:2012/04/28(土) 00:26:20.73
>>13
プライベートアドレスもグローバルアドレスも取得方法は同じ。

17 :デフォルトの名無しさん:2012/04/28(土) 01:43:36.92
多段NAT


18 :デフォルトの名無しさん:2012/04/28(土) 07:08:51.41
MIT NAT 水戸納豆

19 :デフォルトの名無しさん:2012/04/28(土) 10:24:23.98
>>13です

皆さん、ありがとうございました。
試行錯誤して試してみます!

20 :デフォルトの名無しさん:2012/04/29(日) 14:40:57.11
sendとかwriteとかで、すぐに送信しないでちょっとだけ待つロジック
あれなんて名前だっけか? どわすれした

21 :20:2012/04/29(日) 15:02:57.11
思い出しました。 ありがとうございました。

22 :デフォルトの名無しさん:2012/05/01(火) 11:11:35.62
俺は思い出せない、、、なんだっけ

23 :デフォルトの名無しさん:2012/05/01(火) 13:16:25.30
は?
帯域制限のこと?
ロジック?

24 :デフォルトの名無しさん:2012/05/01(火) 13:21:49.64
>>23
アルゴリズムな

25 :デフォルトの名無しさん:2012/05/01(火) 13:21:51.11
NAGELアルゴリズムのことだろ

26 :デフォルトの名無しさん:2012/05/01(火) 13:35:30.16
ナゲル?

27 :デフォルトの名無しさん:2012/05/01(火) 13:40:36.97
なげたらあかん

28 :デフォルトの名無しさん:2012/05/01(火) 13:40:38.10
なんだスタック側の話か
アプリケーションかと思った

29 :デフォルトの名無しさん:2012/05/01(火) 13:41:03.90
そう。パケットを「投げる」からきている。

30 :デフォルトの名無しさん:2012/05/01(火) 13:43:40.61
本人面白いと思ってるんだろうなぁ…

31 :デフォルトの名無しさん:2012/05/01(火) 14:22:53.45
ニコニコ生放送で高速で
アカウント変更とコメントを出来るツールって作れますか?

32 :デフォルトの名無しさん:2012/05/01(火) 14:37:26.38
にしこり

33 :デフォルトの名無しさん:2012/05/01(火) 14:43:00.78
バーレーン

34 :デフォルトの名無しさん:2012/05/01(火) 15:36:38.49
>>30
バーカ

35 :デフォルトの名無しさん:2012/05/01(火) 15:46:32.07
BT PANて使ったこと無いんだが、
あれはこのスレの守備範囲なのか?
いちおうソケットだよな?

36 :デフォルトの名無しさん:2012/05/01(火) 15:56:58.94
>>35
プログラミングは関係ないからなぁ・・・

37 :デフォルトの名無しさん:2012/05/01(火) 16:52:01.71
>>34
悔しかったの? (w

38 :デフォルトの名無しさん:2012/05/01(火) 17:28:34.62
>>37
子ね低脳

39 :デフォルトの名無しさん:2012/05/01(火) 18:32:38.05
>>38
>>37

40 :デフォルトの名無しさん:2012/05/02(水) 15:13:50.42
_ひ

41 :デフォルトの名無しさん:2012/05/04(金) 14:32:56.20
_ふ

42 :デフォルトの名無しさん:2012/05/04(金) 14:36:54.17
ファイル転送するアプリを作っています。

サーバ側に受信ポートを変えて同じEXEを10個立てて、
1000個のクライアントプロセスから10kbのファイルを10個ずつ送信を
行っているのですが、6000ファイルくらい送ると、
クライアント側のconnectがエラーになり始めます。
※connectのerrnoは2(no such file or directory)

これはサーバ側がいけないんでしょうか。
サーバ側のタスクマネージャを見ていても、CPUは張り付いていないし
メモリも食ってないし、帯域もそんなに使用していません。

調査方法でも良いので、どなたかわかりませんでしょうか。


43 :デフォルトの名無しさん:2012/05/04(金) 14:40:49.50
>>42
TIME_WAIT状態のが沢山残っているのでしょう。
netstatで見るとわかると思います。

これを防ぐにはTIME_WAIT時間を短くするか
クライアント側からshutdownさせれば良いはず。

44 :デフォルトの名無しさん:2012/05/04(金) 14:42:19.83
>>42
OS 位書けよ…

まあ、OS 書かない奴の大半は Windows だろうからそれを仮定するけど、
connect( ) 失敗時に見るのは、errno じゃなくて、 WSAGetLastError( )
じゃないのか?

45 :デフォルトの名無しさん:2012/05/04(金) 14:48:58.41
>>44
OSはz/OSです

46 :デフォルトの名無しさん:2012/05/04(金) 15:01:03.82
>>43 たしかに TIME_WAIT と CLOSE_WAIT が沢山ありました。。。

>>44 すみません、Windows2008ServerR2 同士 です



47 :デフォルトの名無しさん:2012/05/04(金) 15:03:18.36
クライアント側の問題だと思うよ(TIME_WAIT累積によるローカルポート枯渇)。
クライアント側もz/OS?何台のマシンでやってるの?

48 :デフォルトの名無しさん:2012/05/04(金) 15:06:59.57
>>46
そんなOSないしw

TIME_WAIT周りに不具合があるみたいだな。
http://salaryman-life.blogspot.jp/2012/04/windows-server-2008-timewait.html

CLOSE_WAIT が残っているのはロジック見直した方がよいと思う。
切断手順がおかしいか

49 :デフォルトの名無しさん:2012/05/04(金) 15:07:06.40
>>47 クライアント側もWindows2008serverです。
   (z/OSではないです)

50 :デフォルトの名無しさん:2012/05/04(金) 15:10:30.03
TIME_WAIT と CLOSE_WAIT が両方あるってどんな繋ぎ方してるのよ?

51 :デフォルトの名無しさん:2012/05/04(金) 15:11:59.55
なんだよWindowsかよ(このやろ!!>>45)。
レジストリで
・使えるローカルポート数を増やす(デフォルト5000個のはず)
・TIME_WAIT時間を短くする(Windowsのデフォルトは凄く長かったと思う)
くらいしかないだろうなあ

52 :デフォルトの名無しさん:2012/05/04(金) 15:15:52.41
>>51
OS/360にしとけば良かったw
ゴメリンコ

53 :デフォルトの名無しさん:2012/05/04(金) 15:17:12.23
>>46
だから、Windows 系なら errno じゃなくて、WSAGetLastError( ) 見なよって
書いてあるんだが…

話は、それからだと思う。

54 :デフォルトの名無しさん:2012/05/04(金) 16:16:18.79
>>53 すみません、遅くなりました。
   WSAGetLastErrorだと、 10061  が返ってきています。

55 :デフォルトの名無しさん:2012/05/04(金) 16:58:27.34
>>54
10061 WSAECONNREFUSED Connection refused.
まんまですな。

で、Shutdown() しているのはどちらから?

56 :デフォルトの名無しさん:2012/05/04(金) 17:11:54.57
>>54
接続切断回数を減らすか
>>51 の言っているようにレジストリをつつくかだな
TcpTimedWaitDelay MaxUsePorts ぐぐれ粕

57 :デフォルトの名無しさん:2012/05/04(金) 18:32:50.40
>>54
WSAECONNREFUSED だから、サーバー側で Listen しきれてないんだろうな。

他の人も言ってる様に CLOSE_WAIT 状態が続いてるのは普通はないから、
クローズ処理を見直したほうがいいと思う。

自分で良くわからないなら、まずはサーバー側とクライアント側の netstat の
概要と、サーバー/クライアントの切断処理を晒せばここの人が何とかしてく
れるかも。

58 :デフォルトの名無しさん:2012/05/04(金) 18:42:06.98
そもそも切断処理をしていないとか。

59 :42:2012/05/07(月) 22:59:56.89
すみません、諸事情でマシンをさわれませんでした。

ソースコードを見直したところ、connectリトライや切断の際に
処理がおかしい箇所があったため、見直して修正しました。

そしたら、CLOSE_WAITはなくなりましたが、TIME_WAITは
かなり発生しています。
また、connectエラー(10061)は相変わらず出ます。
レジストリをいじって、TcpTimedWaitDelay を30にしたところ
だいぶ減ったのですが、10061エラーはあまり改善していません。

調べてみたところ、TIME_WAITは出ても問題ない、どうやっても
出てしまうもの。という記述を多くみました。
とすると、やはりTCPの仕組み上の限界なのでしょうか。

60 :デフォルトの名無しさん:2012/05/07(月) 23:41:56.30
>>59
CLOSE_WAITとTIME_WAITが同時にあるのはおかしい常態だけど
どんな接続や切断の仕方している?
接続はクライアントから? サーバから? 切断は?
どの位の時間間隔で接続数は?

それからTIME_WAITは先に切断要求を出した方に残るのは正常な状態。


61 :デフォルトの名無しさん:2012/05/07(月) 23:44:16.25
ん? connectリトライって何やってんの?
tcpはリトライなんかしちゃいかんよ。

62 :デフォルトの名無しさん:2012/05/07(月) 23:57:52.99
ネットワークのトラブルとかで、connect( ) が一時的にエラーになることもあるから、
常にリトライしないとか言うアホは放置で。

63 :デフォルトの名無しさん:2012/05/07(月) 23:58:23.77
>>59
TcpTimedWaitDelayが30秒だと30秒以内の間隔で連続して
接続・切断を繰り返すとソケットが破綻するのはわかるかな?

64 :デフォルトの名無しさん:2012/05/08(火) 00:09:21.35
>>62
ごめん、言葉足らずだった。
connectから応答がないときのリトライ。
接続できないからと数秒間隔でリトライとか。

Windowsの場合、connectは20秒なんで20秒で繋がらない
状態の場合は直ぐにリトライしても繋がることはほとんどないが。

65 :42:2012/05/08(火) 00:25:29.88
>>60
CLOSE_WAITはなくなって、TIME_WAITだけある状態です。
・接続は、クライアントからconnectしています。(bind無し)
・切断は、クライアント
      →セッション終了を示すコードをsendで送ったあとは
       自らshutdown(cs,2); closesocket(cs); で閉じてます。
     サーバ
      →セッション終了を示すコードがrecvで届いたら、
       こちらも自らshutdown(cs,2); closesocket(cs); で閉じているので
 
なので、切断は同期があまり取れていないのですが、まずいでしょうか。


>>61
connectでエラーが帰ってきたら、5秒待って再度connectしています。
これはまずいでしょうか。。。

>>63
確かに。。。明らかに30秒以内で接続・切断を繰り返しています。
10KB*10ファイルを1セッションで送るプロセス*1000個を同時起動
なので、やはり多すぎでしょうか。。。

66 :デフォルトの名無しさん:2012/05/08(火) 06:34:00.32
>>65
shutdown は SD_SEND でやるのがお行儀の良いやり方だけど
SD_BOTH でも問題は発生することはないんじゃないかな。

>セッション終了を示すコードをsendで送ったあとは
これは何?

connect()は問題なし。

>なので、やはり多すぎでしょうか。。。
切れ目無く連続でやると破綻するでしょうな。

67 :デフォルトの名無しさん:2012/05/08(火) 07:14:08.37
例えば、だけど
0xFFを「終了の合図」と決めておいて

クライアント側は
 0xFFを送る → shutdown
サーバー側は
 0xFFを受け取る → close
ということだろう。

普通に作るならば、クライアント側から切断するのであれば
サーバー側はCLOSEのサイン(recvが0)を待てば良いだけな気がするし
そもそもSENDをshotdownするなら、終了の合図なんて要らないんだけどね。
まあ、将来の可能性も含め、切断せずに繰り返し送受信することを考慮するなら、
そういうやりかたもあるかとも思うけど、
切断時に、両方ともCLOSE前に自分で切ってるのはどうなんだろうね。

68 :デフォルトの名無しさん:2012/05/08(火) 07:35:58.05
C#なんですが
データグラム ソケットで送信されたメッセージが、内部のメッセージのバッファーまたはほかのネットワークの制限を超えています。または、データグラムの受信に使われるバッファーがデータグラムより小さく設定されています。
というエラーが出ることがあるんですがこれはどうすればいいでしょうか?

69 :デフォルトの名無しさん:2012/05/08(火) 11:30:47.29
分割するとか
C#に限らないんじゃ?

70 :デフォルトの名無しさん:2012/05/08(火) 12:24:29.64
Socket.Receiveするときにバイト数を指定すればいいですかね
指定した SocketFlags を使用し、バインドされた Socket から指定したバイト数のデータを受信して、受信バッファ内の指定したオフセット位置に格納します。

71 :42:2012/05/08(火) 13:19:51.41
>>67
仰るとおりの終了の合図をやっています。

切断時に両方からshutdown , closesocket はまずいのでしょうか。
あまりそのあたりに触れているサイトが無くて困っております。

また、今再度確認していて気づいた点があります。
1000プロセスの終盤(残り10プロセスあたり)になると、
connectエラーは起こらないのですが、recv(の前のselect)が
5秒待っても届かずタイムアウトが猛烈に発生します。

この場合、TIME_WAITは30秒経過したからか、殆どなくなって
ESTABLISHEDばかりですが、なぜか非常にrecv,sendが遅く
なっておりました。

NICやHUBが限界なのかなと思えてきました。。。

72 :デフォルトの名無しさん:2012/05/08(火) 13:57:00.46
その切断の仕方だとサーバ側も(タイミングにより)TIME_WAITになるよね?
>>67が言ってるように、サーバー側の切断は「終了の合図」でやるのではなく、
recvで0が返ってきた時にやるようにすれば問題ないと思うけど。

73 :デフォルトの名無しさん:2012/05/08(火) 14:03:01.27
>>70
普通にsend側で分割する。receive側でサイズ指定してもダメ。

74 :デフォルトの名無しさん:2012/05/08(火) 19:23:20.79
>>71
>切断時に両方からshutdown , closesocket はまずいのでしょうか。

問題ないです。

>あまりそのあたりに触れているサイトが無くて困っております。

Winsockと言えばここでしょう。サンプル見れば切断手順がわかると思います。
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/

>1000プロセスの終盤(残り10プロセスあたり)になると、

1台のPCで1000プロセスだとそもそも無理があると思いますが。

>connectエラーは起こらないのですが、recv(の前のselect)が
>5秒待っても届かずタイムアウトが猛烈に発生します。

select()のタイムアウトとは?

>NICやHUBが限界なのかなと思えてきました。。。

そりゃ無いです。ファイルコピーなんか何百ギガも転送したりしますんで。

75 :デフォルトの名無しさん:2012/05/08(火) 19:26:00.66
DoS攻撃認定されてブロックされてる、とか言うオチはやめてくれよ。

76 :デフォルトの名無しさん:2012/05/08(火) 20:04:13.19
>>75
昔、俺もやらかしたな
ネットワーク構成図に載ってないFWが間にあって、通信を殺されてたww

77 :デフォルトの名無しさん:2012/05/08(火) 20:12:44.70
そんなんだと割りと簡単にわかるだろう

78 :デフォルトの名無しさん:2012/05/08(火) 20:57:32.00
>>71
クライアント側は1台で1000コネクションなんてことは無いでしょうから
TIME_WAITで破綻なんかしないのでは?
テストのやりかたが悪いと思う。

79 :デフォルトの名無しさん:2012/05/10(木) 23:29:09.16
すごく初歩的な質問で申し訳ないのですが、現在コンピュータが行っている接続を
すべて取得する手段はどのようなものが考えられるのでしょうか。

80 :デフォルトの名無しさん:2012/05/11(金) 00:29:09.08
>>79
netstat -a


81 :デフォルトの名無しさん:2012/05/11(金) 01:21:24.11
そーだね

82 :デフォルトの名無しさん:2012/05/18(金) 00:54:20.27
WiFiでPCからAndroidに作業をさせるようなアプリを作っています。

サーバ側をAndroid、クライアント側をWindowsXP、IPとPort固定で接続しています。
クライアントからサーバに接続しようとすると、初回はだいたいうまくいくのですが
BindException: address already in useが出て接続できない時があります。
ServerSocketクラスのsetReuseAddressやsetSoLingerなどのメソッドを試してみましたが
それでも接続できないことがあります。
Java(というかTCP)の仕様なのでしょうか?
希望としては接続・切断を繰り返しても問題なく接続できるようにしたいのですが、、
いい方法があれば教えてください。

83 :デフォルトの名無しさん:2012/05/18(金) 05:47:04.16
>>82
少し前にもあったけど、どの程度の頻度で接続を繰り返しているのか?
切断手順に誤りはないか?をまずは確認してください。

頻繁に接続切断を繰り返したり、数分間切断された状態が続くとやばい
とかなら、素直にUDP使っとけやと思います。

84 :デフォルトの名無しさん:2012/05/18(金) 14:11:54.13
>>82
>IPとPort固定で接続しています。
もしかしてクライアント側も特定ポートにバインドしてるとか?
>BindException: address already in use
はまさにそれっぽいんだが

85 :デフォルトの名無しさん:2012/05/18(金) 20:20:53.96
>>84
次はサーバ側が多重化されていないので問題が発生する
とエスパーしてみる。

86 :82:2012/05/19(土) 01:31:24.31
ありがとうございます。

>>83
30秒〜1分くらいです。
切断手順は、shutdown→closeみたいな感じでしょうか。
今はcloseだけ行っています。

>>84
クライアント側もサーバのポートを指定して、サーバに接続しています。
サーバ側でBindは呼んでいますが、クライアント側では意識してBind呼んだりは
していません。

87 :デフォルトの名無しさん:2012/05/19(土) 08:10:23.65
>>86
>今はcloseだけ行っています。
お行儀わるいぞ。こうだろ。

shutdown(send) → recv(0) → shutdown(recv) → close

88 :デフォルトの名無しさん:2012/05/19(土) 21:29:36.96
>>87
そんなことやんねーよバーカ
何年前の世界に生きてんだ

89 :デフォルトの名無しさん:2012/05/19(土) 22:26:25.38
>>88
そ、そうなのか・・・w

90 :デフォルトの名無しさん:2012/05/19(土) 23:02:07.68
>>89
相手が切断したことを確認する必要があるかどうか
無いならいきなりcloseでいい

91 :デフォルトの名無しさん:2012/05/20(日) 00:05:07.59
>>85
俺の過去が見えるのか!

92 :デフォルトの名無しさん:2012/05/20(日) 04:09:43.58
久々に来たけど、ここ相変わらず面白いね。
無知とは言え無茶しすぎだろう。

自分の管理下のpcや鯖相手に好き勝手試すのはどうぞ存分に遣ってくれと思うけど、ネット上の鯖とかには控えめにな。サーバ攻撃受けたと判断されて通報されそうだわw

93 :デフォルトの名無しさん:2012/05/20(日) 07:19:33.49
『朝鮮総連』は色々な企業のホームページからホストコンピューターに進入し、自分達が隠したプログラミングを引き出す…他人の会社のサーバーに『挺陝馗操作』や『改竄red-hat』のクラッカープログラム保管場所にしている。
札幌市立啓北商業高校の野島(横濱)えり Microsoft USA co.tp.
弖十=TEN10(teto)=優多野手頭=野慈蚕=帝跿(徒)=衛鴉朧 笑狸乃雉匯

94 :デフォルトの名無しさん:2012/05/20(日) 09:17:27.67
>>90
shutdown(both)も要らないのか?

95 :デフォルトの名無しさん:2012/05/20(日) 09:44:54.47
>>90
大した手間じゃないんだから定石通りの
切断手順を踏んだ方が良いと思うけどね。

96 :デフォルトの名無しさん:2012/05/20(日) 09:53:02.04
>>94
close内で勝手に呼び出す

>>95
カーネル内部で定石通りに勝手にやる

97 :デフォルトの名無しさん:2012/05/20(日) 10:08:01.05
>>96
カーネル側でちゃんと処理してくれないOSもあるのか?
でなきゃTIME_WAITもあるし常にclose()のブチ切りで良くなる。

98 :デフォルトの名無しさん:2012/05/20(日) 13:18:31.48
>>86
>30秒〜1分くらいです。

>サーバ側でBindは呼んでいますが、クライアント側では意識してBind呼んだりは
>していません。

だとすると、それにも関わらずBindException: address already in use
になるのは変だね。実は切断がちゃんと出来てないとか、クライアントの
マシンで別のアプリが大量にポート消費してるとか?netstatは見てみた?

99 :デフォルトの名無しさん:2012/05/20(日) 13:26:10.26
>>98
Bind()しているのはサーバ側のリスナーのポートだけじゃない気がするw

100 :デフォルトの名無しさん:2012/05/20(日) 17:39:30.12
>>97
だから基本的にはclose()ブチ切りで問題ない

shutdown()を使うべきなのは、データ送信後に相手が
受け取れたかどうかを見届けたいときくらいなものだ

101 :デフォルトの名無しさん:2012/05/20(日) 17:55:57.93
>>100
shutdown(SD_BOTH)の存在価値は全くないと・・・

102 :デフォルトの名無しさん:2012/05/20(日) 18:26:28.33
そもそも shutdown( ) [通信の停止] と close( ) [資源の解放] は、用途が違うんだから、
ぶち切りなら shutdown( ) は不要とか言ってるアホはスルーでいい。

プログラムの作りによって、通信はやめたいけど、資源の解放はあとの方でまとめてや
るなんてことはいくらでもありうる。

※ しかし、なんで shutdown( ) なんて名前なんだろう?
※ 素直に disconnect( ) とかでいいように思うが、8文字制限か?

103 :デフォルトの名無しさん:2012/05/20(日) 18:27:35.85
serverとclientを区別するためジャマイカ

104 :デフォルトの名無しさん:2012/05/20(日) 19:06:12.75
>>102
そういうときだけshutdown使えばいいじゃん
適材適所って言葉知ってる?

105 :デフォルトの名無しさん:2012/05/20(日) 19:27:29.76
unixの実装だとまずい事が起きる場合があるそうですな。

2.6 shutdown() はどういうときに使うべきなのですか?
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-2.html

winsockだと大丈夫かな。

106 :デフォルトの名無しさん:2012/05/20(日) 19:31:37.33
ソケット周りはBSDの実装をずーっと引きずっているし
高速回線にはそぐわないパラメータ値も多いし。

107 :デフォルトの名無しさん:2012/05/20(日) 19:40:00.92
>>104
>適材適所って言葉知ってる?

だから、単純に

shutdown()を使うべきなのは、データ送信後に相手が
受け取れたかどうかを見届けたいときくらいなものだ

108 :107:2012/05/20(日) 19:42:07.67
>>107
途中で送信しちゃった。

>適材適所って言葉知ってる?

だから、

> shutdown()を使うべきなのは、データ送信後に相手が
> 受け取れたかどうかを見届けたいときくらいなものだ

以外のケースもあると書いてあるんだが、日本語理解できない?

それとも、なんか悔しかったのか?(w

109 :デフォルトの名無しさん:2012/05/20(日) 20:00:47.13
あとでまとめて資源解放って、作りの良さ的にはどうなんだろうか

110 :デフォルトの名無しさん:2012/05/20(日) 20:38:43.69
>>109
あとでまとめて解放なら放置プレイしてOSに解放させれば良いのでは?

111 :デフォルトの名無しさん:2012/05/20(日) 20:48:22.36
それならさっさとクローズした方がいいな。

112 :デフォルトの名無しさん:2012/05/20(日) 20:51:30.92
お気軽に都度プロセス起したり頃したりする組み方のサーバーやクライアントの通信モジュールなら有だと思う。

113 :デフォルトの名無しさん:2012/05/20(日) 21:09:29.93
fdをそのソケットにかかわる他のプログラム内部資源の識別にも使っている作りだと、
通信の停止とclose()を別々に行うことはあるね。
あまりいい作りとは思えないけど、手軽なんで周りでも時々見かける。

114 :デフォルトの名無しさん:2012/05/21(月) 08:21:07.90
>>113
なんにせよshutdownしてcloseせず長々と持ってるつくりは
感心できるものじゃないなぁ

115 :デフォルトの名無しさん:2012/05/21(月) 16:30:28.64
>>102
> プログラムの作りによって、通信はやめたいけど、資源の解放はあとの方でまとめてや
> るなんてことはいくらでもありうる。

こんな作りにしたこともしたくなったことも、いまだかつて無い。

116 :デフォルトの名無しさん:2012/05/21(月) 16:44:17.44
論破したくて無理やり思いつきました

117 :デフォルトの名無しさん:2012/05/22(火) 07:58:43.54
ぶち切りって、あんまりファイヤウォールでは想定されてなくて、暫く続きのパケット来るか待ち続けちゃってそうw
一万セッションぐらい通してみて誰か耐久試験でもやってくれw

ftpなんかも制御持ち切りでデータのほうばっかで流してるうちに、切られてたりはするな。
ゲームとかでも描くパーツの制御にそれぞれ制御セッション貼って、データだけいろいろ送って、状態推移に使ってたりして。

>>112
tftpなんて毎回貼り直しでもいいくらいヌルいね。
httpなんかでも地図データ拾うのに使い捨ての様にセッション貼ってるけど。

118 :デフォルトの名無しさん:2012/05/22(火) 10:52:40.38
>>117
その耐久試験ならすでに何億回とやってる。

119 :デフォルトの名無しさん:2012/05/22(火) 17:23:16.46
どちら側も同じポート番号で複数の接続を処理する場合、
shutdownだけしてcloseする処理はありうる。
ずっと待ち受け続けられるから。

ただクライアントサーバ方式全盛だから、
こういうランデブー型の双方からconnectする通信方式は少ないな。
ちなみにTCPのRFCにはランデブー型APIについて書いてあった。
BSDソケットはこの辺を生真面目に設計、実装していると思われる。

120 :デフォルトの名無しさん:2012/05/22(火) 17:24:27.51
>>119
> shutdownだけしてcloseする処理はありうる。
< shutdownだけして、closeせずにsocketを維持し続ける処理はありうる。

121 :デフォルトの名無しさん:2012/05/22(火) 17:28:26.00
>>120
いや、そんな行儀の悪い対向はそうそういないだろうよ・・・
shutdown送ってんのにペラペラ喋り続けるやつは
問答無用でぶっ殺すわ・・・

122 :デフォルトの名無しさん:2012/05/22(火) 17:40:17.11
shutdownしたら、connectしなおすんですよ。

123 :デフォルトの名無しさん:2012/05/22(火) 17:41:41.22
You're correct.

124 :デフォルトの名無しさん:2012/05/22(火) 20:21:48.69
>>117
close()でぶち切りしてもプロセスをKillしてもOS側で必要な切断手順は
やってくれるのでプロトコルの途中でのぶち切りにはならない。


125 :デフォルトの名無しさん:2012/05/22(火) 21:05:49.86
closeというかCloseHandleを無視するとかいうイカレポンチな代物がWindowsにはあったりするからなー(棒
ttp://msdn.microsoft.com/en-us/library/windows/desktop/ms724935%28v=vs.85%29.aspx

126 :デフォルトの名無しさん:2012/05/22(火) 21:13:44.54
WinsockはclosesocketとshutdownのMSDNドキュメントは必ず読まないとヤバイ。
Graceful Shutdown, Linger Options, and Socket Closure.も読んどけ。

127 :デフォルトの名無しさん:2012/05/22(火) 22:24:40.80
>>116
そんなに悔しかったのか? (w

>>124
いったいどこのプロトコルの話をしてるんだ?

128 :デフォルトの名無しさん:2012/05/22(火) 23:08:44.91
>>124
安いプロトコルスタック買っちゃったら
このあたりの尻拭いしてくれないよね

129 :デフォルトの名無しさん:2012/05/22(火) 23:59:18.39
SSL Proxyの簡単なやつを作ってみたいのですが
何か参考書知りませんか?
LinuxかAIXでプログラム作れたら嬉しいです

130 :デフォルトの名無しさん:2012/05/23(水) 03:56:53.89
winsockとかなんちゃってipスタックだとその辺適当で、上手く動かない罠に嵌るだろうな。
枯れてるipスタックって結構大事。

aixならibmの営業捕まえて研修受けてこい。もちろんお金は掛かるけど。
簡単にsslでproxyできたらsslの意味無くなると思うけどね。
あんたが銀行サイトにsslで繋げて安全と思ってるのに、途中でproxy挟まれて中身見れてたら意味無いでしょ。

131 :デフォルトの名無しさん:2012/05/31(木) 01:50:51.64
趣味でやってる程度なので初歩的な質問ですいません。
以前TCPを利用した対戦ゲームを作って友人と遊んでいたのですが、
引越しで環境の変化により接続できなくなりました。

原因はマンションの回線を使っているためだと思われます(そもそもポート開放できない
が、プログラムの組み方でその辺の問題を回避できたりしますか?
ネットゲームや、DS・PS3等のネット通信はできるので、接続は絶望的ではないのかなと思い質問しました。
TCPでの接続ができないとしたら、他の通信方法などがあれば教えてもらえると嬉しいです。

132 :デフォルトの名無しさん:2012/05/31(木) 11:17:56.93
可能です
では次の方どうぞ

133 :デフォルトの名無しさん:2012/05/31(木) 17:59:17.46
>>131
VPNでつないどけ

134 :デフォルトの名無しさん:2012/05/31(木) 18:14:35.51
セルンか


135 :デフォルトの名無しさん:2012/05/31(木) 18:15:02.94
両端ともCATVみたいにNATの内側だとつらくね?

136 :デフォルトの名無しさん:2012/05/31(木) 23:07:04.79
メールベースで互いの行動をやりとりする

137 :デフォルトの名無しさん:2012/06/01(金) 19:47:51.93
>>135
SoftEtherでも使っとけ

138 :デフォルトの名無しさん:2012/06/01(金) 20:21:20.48
>>137
誰でも使えるpublicなサーバーとかあるんだっけ?

139 :デフォルトの名無しさん:2012/06/02(土) 13:57:42.79
>>135
物理層を伝書鳩にすればいいと思うよ。

140 :デフォルトの名無しさん:2012/06/02(土) 14:08:51.19
>>139
それでもダメだろ。面白いこと言ったつもりだろうけど、よく考えろ。

141 :デフォルトの名無しさん:2012/06/02(土) 14:51:32.95
やっぱ物理層はスマホだよな

142 :デフォルトの名無しさん:2012/06/03(日) 00:12:26.49
ネットワークプログラミングって固定長が基本なのですか?
送られてきたデータをパースするときは、どんな感じでパースしてますか
普通に固定長ファイルを扱う感じでやろうかと思うのですが


143 :デフォルトの名無しさん:2012/06/03(日) 00:19:46.49
いえ、(可変長な)テキストが基本です。HTTPもFTPもSMTPもPOP3もみんなテキストです。
DNSはバイナリですがやっぱり可変長です。

144 :142:2012/06/03(日) 00:30:12.12
>>143
回答ありがとうございます。
ネットワークプログラミングってパフォーマンスを考えなければ簡単そうですね
ちょっと面倒なファイルの操作ってイメージ

145 :デフォルトの名無しさん:2012/06/03(日) 00:32:30.07
レイヤによる

146 :デフォルトの名無しさん:2012/06/03(日) 03:44:27.11
分散コンピューティングになるので、
ローカルファイル扱いとは
本質的に違うところが随分あります。

147 :デフォルトの名無しさん:2012/06/03(日) 08:31:26.79
ネットワークカメラからデータ受けたり、ネットワークプリンタにデータ吐いたりするのも
ネットワークプログラミングなので、一律に「分散コンピューティング」とか言うのは、
すごく違和感がある。

148 :デフォルトの名無しさん:2012/06/03(日) 21:32:46.41
HTTPで302が来た場合一旦socketをcloseして繋ぎなおしたほうがいいですか?
それともリクエストをやり直すだけでOKですか?
また、こういう情報はどこに記載されています?

149 :デフォルトの名無しさん:2012/06/04(月) 10:24:07.14
RFC

150 :デフォルトの名無しさん:2012/06/04(月) 10:35:13.70
>>149
RFCの何番かくらい教えてやれよ・・・

151 :デフォルトの名無しさん:2012/06/05(火) 10:50:32.49
簡単なチャットプログラムのようなものを作りたいんだけど
UDPでブロードキャストしまくるのって下品?

152 :デフォルトの名無しさん:2012/06/05(火) 17:42:00.38
簡単なチャットプログラムのようなものならいいんじゃない?

153 :デフォルトの名無しさん:2012/06/05(火) 18:49:46.51
ブロードキャストで届く範囲ならいいんじゃないの?
所詮チャットて程度の帯域利用なんだから。

154 :デフォルトの名無しさん:2012/06/05(火) 22:22:52.97
それで自分だけは他人宛のメッセージを読めるようにすると

155 :デフォルトの名無しさん:2012/06/07(木) 08:53:40.29
DNSに関したプログラム作りたいんだけどまずUDPしっかりやってからですかね?

156 :デフォルトの名無しさん:2012/06/07(木) 10:29:33.62
UDP自体にしっかりやるほど難しいことはありません
それより関連RFCをよく読んで仕様を頭に叩き込んでください

157 :デフォルトの名無しさん:2012/06/07(木) 13:47:30.82
aとかaaaaとかptrとか引いて喜んじゃう程度なら
頭を叩いてまで詰め込むようなことはないような。

158 :デフォルトの名無しさん:2012/06/10(日) 22:02:32.03
ネットワークプログラミングやってみたいんだけど、何か面白そうなお題ない?

159 :デフォルトの名無しさん:2012/06/10(日) 23:09:26.19
p2p

160 :デフォルトの名無しさん:2012/06/10(日) 23:38:40.73
最初はチャットからだろうな

161 :デフォルトの名無しさん:2012/06/11(月) 13:13:54.37
ゲーム

162 :デフォルトの名無しさん:2012/06/11(月) 15:24:41.21
winsock2を使用してUDPのデータ送信プログラムを作成しています。

sendto()に10000バイトを指定して実行し、戻り値が10000である事を確認しました。
この状態で送信先のPCにアナライザソフト(PacMon最新版)を入れてデータを確認しましたが、
1パケット分(パケット長1514バイト、データ長1472バイト)しか届いていません。

残りのデータは何処に行ってしまったのでしょうか?
2台のPC共にネットワークカードのジャンボフレームは無効にしてあります。

163 :デフォルトの名無しさん:2012/06/11(月) 16:34:09.05
気にするな

164 :デフォルトの名無しさん:2012/06/11(月) 17:59:30.50
Wiresharkでキャプチャしてみるとどうなるかな?

165 :デフォルトの名無しさん:2012/06/11(月) 18:22:28.76
>>162
おれが食っちまった

166 :デフォルトの名無しさん:2012/06/11(月) 21:41:28.71
>>125
最近はMSDNもメトロデザインなのね。
なんか殺風景なのね。

167 :デフォルトの名無しさん:2012/06/11(月) 22:38:29.59
>>162
天使の取り分

168 :デフォルトの名無しさん:2012/06/11(月) 23:03:07.09
分け前じゃなかったっけ?

て言うか、8割以上ぶんどる天使って、悪魔じゃねーのか?(w

169 :デフォルトの名無しさん:2012/06/11(月) 23:10:42.04
100送って1しか届かなくても、残り99が後から届かないとはかぎらない

170 :162:2012/06/11(月) 23:48:49.34
Wiresharkを使って見ましたが1パケットも届かなくなりました。
送信バイト数を10Kではなく1KにするとWiresharkでも届いてる事を確認できます。

普通は複数パケットに分割されて届くのでしょうか?
それともsedto()の戻り値が10Kなのが変なのでしょうか?

171 :デフォルトの名無しさん:2012/06/11(月) 23:49:08.45
UDPなら魔空空間に呑まれて終わりだろ

172 :162:2012/06/11(月) 23:54:15.09
Wiresharkを使って見ましたが1パケットも届かなくなりました。
送信バイト数を10Kではなく1KにするとWiresharkでも届いてる事を確認できます。

普通は複数パケットに分割されて届くのでしょうか?
それともsedto()の戻り値が10Kなのが変なのでしょうか?

173 :デフォルトの名無しさん:2012/06/11(月) 23:58:59.12
UDPならどこで蒸発しても文句は言ってはならない…
…たとえそれがNIC(って最近オンボードの方が多いけど)に渡る前であっても、
send(to)に渡した直後であってさえも、だ…

174 :デフォルトの名無しさん:2012/06/12(火) 00:00:07.88
>>1
Programming UNIX Socket FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/sock-faq/indexj.html
Winsock Programmer's FAQ (日本語訳)
http://www.kt.rim.or.jp/~ksk/wskfaq-ja/
以下略

175 :デフォルトの名無しさん:2012/06/12(火) 00:16:20.07
こまけえことはきにするな

176 :デフォルトの名無しさん:2012/06/12(火) 01:38:38.83
>>172
環境依存です。
今なら複数パケットに分割して配信する環境の方が多いでしょう。
実際にどうなるかは、経路上のネットワーク機器次第なので、
インターネットでどうなるかは運次第ですね。


177 :デフォルトの名無しさん:2012/06/12(火) 02:14:31.19
>>176
>今なら複数パケットに分割して配信する環境の方が多いでしょう。
UDPを分割配信する処理系があるならぜひ教えてもらいたいものです

178 :デフォルトの名無しさん:2012/06/12(火) 07:23:24.73
え?

179 :デフォルトの名無しさん:2012/06/12(火) 08:44:13.73
>>177
WindowsとかLinuxとか

180 :デフォルトの名無しさん:2012/06/12(火) 09:37:02.65
>>172
IPフラグメンテーションという仕組みがあり、UDPパケットのサイズが大きく
MTUのサイズを超えてしまう場合には、複数のIPパケットに分割して格納される。
ただしルーター側で無効にしている場合もあります。

PacMonやWiresharkでUDPパケットをキャプチャー出来ないのは、
おそらくIPフラグメンテーションで分割されたUDPパケットを解析する
機能が無いからです。

IPパケットを自力で解析すれば、そこには分割されたUDPパケットが
格納されてると思います。

181 :デフォルトの名無しさん:2012/06/12(火) 11:30:00.93
>>180
>IPフラグメンテーションという仕組みがあり、UDPパケットのサイズが大きく
>MTUのサイズを超えてしまう場合には、複数のIPパケットに分割して格納される。
>ただしルーター側で無効にしている場合もあります。

・その分割されたパケットはどこで(ex: 受信側のUDPスタック)組み立てるの?
・分割された複数パケットの到着順序が崩れたり(or 反転したり)、ロストした場合はどう振る舞うの?
・これらはプロトコル仕様書(RFC)のどこに記述されているの?

IPフラグメンテーション機能が活躍するのはTCPの場合だけだよ
UDPやICMPといったプロトコルの場合、
・送信側UDPスタックでは、IPヘッダ内にあるフラグメント禁止ビットをオンにしてパケットを送信
・途中のルータはフラグメントが必要になった場合、(フラグメント禁止だから)パケットを破棄し、
 送信元へはICMPの未到達(unreachable)メッセージを返す
というのが一般的な実装だと記憶していたのだけどなあ....

182 :デフォルトの名無しさん:2012/06/12(火) 12:14:47.34
>>181
>・その分割されたパケットはどこで(ex: 受信側のUDPスタック)組み立てるの?
受信側のIPスタックが組み立てるにきまってるだろ。

>・分割された複数パケットの到着順序が崩れたり(or 反転したり)、ロストした場合はどう振る舞うの?
複数パケットの到着順序が崩れたら、正しい順番に並びかえる。
ロストしたら破棄される。

>・これらはプロトコル仕様書(RFC)のどこに記述されているの?
STD-5だよ。

>・送信側UDPスタックでは、IPヘッダ内にあるフラグメント禁止ビットをオンにしてパケットを送信
>・途中のルータはフラグメントが必要になった場合、(フラグメント禁止だから)パケットを破棄し、
> 送信元へはICMPの未到達(unreachable)メッセージを返す

それこそRFCの何処に書いてあるんだよ?


183 :デフォルトの名無しさん:2012/06/12(火) 12:49:36.11
また馬鹿がわいてるな
APでやれよ162

184 :デフォルトの名無しさん:2012/06/12(火) 13:23:15.95
UDPでIPフラグメンテーションなんて使うな。仕事だったら地獄を見るぞ。
暇つぶしならどうでも良いけど。

185 :デフォルトの名無しさん:2012/06/12(火) 13:29:56.41
TCP/IP
UDP/IP

186 :デフォルトの名無しさん:2012/06/12(火) 13:57:16.62
>>182
>受信側のIPスタックが組み立てるにきまってるだろ。

ほう、IPスタックに分割されたパケットを組立てる機能があるとは初耳だ
自分の知識ではIPパケットの組み立ては(受信側の)TCPスタックの機能なんだけどね....
それはどこに書いてあるの?(RFCならbestだけど、解説文書へのリンクでもokだよん)

>複数パケットの到着順序が崩れたら、正しい順番に並びかえる。

これも「どこ」で処理されるの?UDPスタック? それとも アプリケーション?
自分の知識ではパケット順序性の保証はTCPスタックの機能(責任)なんだけど、
今の議論の文脈だと「TCPは無関係」だよね?

>STD-5だよ。
RFC番号をヨロシク

>それこそRFCの何処に書いてあるんだよ?

まず自分のカキコに誤りがあったので訂正する
送信元へ返されるICMPメッセージについて、>>181では「未到達(unreachable)」と書いたけど、
これは "fragmentation needed and DF set" に訂正する

次に、この自分は知らないよ
少なくとも RFC 768 - User Datagram Protocol に、IPフラグメントに関する記述は無い
というか、そもそもUDPではパケットが分割されることを想定して設計されていない
送信元が分割(フラグメンテーション)が起きない長さで送出することを期待している
これを実現するのが RFC1191 - Path MTU Discovery だ
日本語で書かれた解説へのリンクを紹介しておく

@network Cisco・アライド実機で学ぶ > TCP/IP入門 > Path MTU Discovery
 http://atnetwork.info/tcpip/tcpip91.html

187 :デフォルトの名無しさん:2012/06/12(火) 14:05:48.19
無知すぎて話にならない

188 :186:2012/06/12(火) 14:08:47.79
細かい点でタイポがあったので>>186を訂正
X: 次に、この自分は知らないよ
O: 次に、これが何処に書いてあるのか自分は知らないよ

あと、"fragmentation needed and DF set" の DF は don't fragment の略語

189 :162:2012/06/12(火) 14:34:51.96
色々アドバイス有り難うございます。

難しくて理解できていませんが・・・

1,環境依存である。
2,送信側から10Kを送信しても途中の機器が10KバイトのMTUに対応していない場合には、
 分割される。(UDPも分割される???)
3,分割されない場合には破棄されて、ICMPエラー通知が届く。


1と3の状況なのかなぁと思っています。
対応しているMTUを越えた場合に全部が破棄されずに先頭1514バイトだけが届くなんて事はありえますか?



190 :デフォルトの名無しさん:2012/06/12(火) 14:37:29.55
パケット監視じゃなくて受信してみろよ

191 :デフォルトの名無しさん:2012/06/12(火) 14:40:52.00
>>186
>ほう、IPスタックに分割されたパケットを組立てる機能があるとは初耳だ

そうか。勉強になってよかったな。
その事もSTD-5に書かれてるから読んだ方がいいよ。

>>複数パケットの到着順序が崩れたら、正しい順番に並びかえる。
>これも「どこ」で処理されるの?UDPスタック? それとも アプリケーション?

IPスタックが処理するんだよ。

>RFC番号をヨロシク
(´・ω・`)

>まず自分のカキコに誤りがあったので訂正する

細かい間違いを論ったりするほど狭量じゃないから安心していいよ。


192 :デフォルトの名無しさん:2012/06/12(火) 17:31:31.80
UDPを再結合なんて聞いたこと無いんだが
どこの惑星の話?

193 :デフォルトの名無しさん:2012/06/12(火) 17:33:02.36
ああ、IPの分割とごっちゃになっちゃってるのか

194 :デフォルトの名無しさん:2012/06/12(火) 18:10:55.25
銀河帝国だろうjk

195 :デフォルトの名無しさん:2012/06/12(火) 19:55:04.85
>>187
残念ながらわが国にはそういう輩がSEやプログラマーと名乗っているのだよ。
他の技術系の職種では信じられない事であるがな。

196 :デフォルトの名無しさん:2012/06/12(火) 20:00:50.08
昔は元コンビニ店員がいたなー、もちろん経験0

197 :デフォルトの名無しさん:2012/06/12(火) 22:42:51.01
>>189
>先頭1514バイトだけが届くなんて事はありえますか?
180にも書いたが、恐らくはちゃんと10KB全部ちゃんとネットワーク上を流れている。
ただ189の知識不足できちんと解析できていないだけ。

184や186の言うとおり、UDPはMTUサイズを超えないように使うのが一般的だし、
MTUサイズを超えた場合は通信障害が起きやすくなる。

素直にUDPパケットが1KB程度になるようにプロトコルを設計しなおした方がいい。


198 :デフォルトの名無しさん:2012/06/12(火) 23:42:43.04
そういうのってユーザプログラム側が意識しなくてもいいようになってるんじゃないの?
ドライバ作ってるとかならそうなんだろうけど

199 :デフォルトの名無しさん:2012/06/13(水) 00:22:36.43
>>198
UDPはデータは消えてなくなっても文句を言えない仕様だから
結構意識する必要がある
でかいパケットはまず間違いなく後ろカットされるし

200 :デフォルトの名無しさん:2012/06/13(水) 00:26:07.44
仕様に定められているものを仕様通りに使って問題あるかもしれないってのは
また別の話だと思うがな。

201 :デフォルトの名無しさん:2012/06/13(水) 00:53:56.64
でかいパケットはドライバ側がやる仕事だろう
プログラム側は一度に送ろうが小出しにしようが関係が無い

202 :デフォルトの名無しさん:2012/06/13(水) 09:44:46.78
本スレ>>1の「Programming UNIX Socket FAQ (日本語訳)」には、
まさに今回の現象(>>162)が解説されている

Q: 5.8 データグラムの最初の部分しか届かないんですが、どうしてなんでしょうか?
A: プラットフォームによっては(MTU値のため)データグラムを分解し、
 そして相手側で再構成させるIP断片化をサポートしているものもありますが、
 しかし全ての実装がこれをサポートしているわけではありません。

で、Windows実装はというと、同じ>>1の「Winsock Programmer's FAQ (日本語訳)」によれば、

Q: 3.6 - UDP って何? どんな制限があるの?
A: プロトコルスタックは、UDPデータグラムの大きさがネットワークのMTUより大きいときは、
 データグラムを分割します。通信相手側のスタックはその分割片から完全なデータ グラムを
 再び組み立ててから受信側のプログラムに渡します。もし分割片の一部が失われたり
 壊れていたりしたときは、そのデータグラム全体が捨て去られます。このため、
 巨大なデータグラムを送るのはあまり実用的ではありません。例えば、8KのUDP データグラムは、
 Ethernet 上に送信されると、6つの塊に分割されます。もしこの6個の分割片のう ち一つでも
 喪失したり壊れたりすると、8Kのデータグラム全体が捨てられてしまうのです。

とあり、Windows実装では(効率性を無視すれば)分割/再構成ともサポートされていると解釈できる
でも、これでは今回の現象(>>162)を説明できない
正しく実装されているなら、全データ(10KB)が到着するか全て破棄されるかのどちらかになるはず
>>162の現象把握のどこかに見落としがあるのか、それともこれらFAQ集に誤りがあるのか....???

203 :デフォルトの名無しさん:2012/06/13(水) 10:06:48.98
おつむがなければMSにお布施を払って聞けよ

204 :デフォルトの名無しさん:2012/06/13(水) 11:48:37.98
>>202
再構築はOS側のスタックで行われるが、
>>162はアナライザで見てるから。

205 :デフォルトの名無しさん:2012/06/13(水) 18:07:17.02
久々に伸びてると思ったら
何年も前の話がループしてるのか


206 :デフォルトの名無しさん:2012/06/13(水) 20:21:46.41
誰もが通る道だからかと

207 :デフォルトの名無しさん:2012/06/13(水) 20:44:46.61
とおんねーよ

208 :デフォルトの名無しさん:2012/06/13(水) 20:47:29.16
誰かが通る道だからかと


209 :デフォルトの名無しさん:2012/06/13(水) 20:49:27.90
なんのために過去スレがあるんだ

210 :デフォルトの名無しさん:2012/06/13(水) 21:02:27.10
あなたは幾多ある過去スレすべて目を通しましたか?

211 :デフォルトの名無しさん:2012/06/13(水) 21:05:45.85
>sendto()に10000バイトを指定して実行し、戻り値が10000である事を確認しました。
10000バイトの中身を比較したとは書いてないところが...

212 :デフォルトの名無しさん:2012/06/13(水) 21:52:55.96
>>211
落ち着いて>162を読み返すんだ

213 :デフォルトの名無しさん:2012/06/13(水) 22:28:24.48
送れた事実が書いてあるだけで
受け取ったとは書いてないような?

214 :デフォルトの名無しさん:2012/06/13(水) 22:42:37.33
>>212
落ち着け
比較した結果もそこに書いてある

215 :212:2012/06/13(水) 22:44:25.94
おk
深呼吸した

216 :デフォルトの名無しさん:2012/06/13(水) 23:33:17.00
全部受け取ったとは書いてないような?

217 :デフォルトの名無しさん:2012/06/13(水) 23:34:57.15
受信できるか保証されてないのに、分割送信しようとするのはおかしくねえか?

218 :デフォルトの名無しさん:2012/06/13(水) 23:41:27.51
受け取れませんと質問してるのに、比較しろというのはおかしくねえか?

219 :デフォルトの名無しさん:2012/06/13(水) 23:44:18.80
自分で答え書いて、それ以上のことができるとでも言ってるのかな?
できないなら、それ踏まえて、別な方法考えないと

220 :デフォルトの名無しさん:2012/06/13(水) 23:50:16.10
>>217
分割しようがしまいが受信できる保証はないが?

221 :デフォルトの名無しさん:2012/06/14(木) 00:07:55.50
深呼吸しようぜ
・10000バイト、Winsockにデータを与えた(この時点で送信などしていない)
・データを受け取りましたと返した(同上)
・相手の状態見たらさきっぽだけ出てきた(少なくとも、さきっぽだけ送信側が送信した)
なにもおかしくないよね

222 :デフォルトの名無しさん:2012/06/14(木) 00:25:15.63
ip fragment(rfc791)
やりますとは書いてあるけど、実際やってどうなるかの保証はないでしょ、UDPだから

MTUが512を想定して、考えたな、昔

223 :デフォルトの名無しさん:2012/06/14(木) 10:35:38.37
データ受け取ってないから問題なんだよ。
アナライザで見ただけ。
最初に受け取るコードかいてりゃこんなとこ来てないw

224 :デフォルトの名無しさん:2012/06/14(木) 10:51:40.65
同じ轍を通ってることを嘲笑うだけで誰一人解決策を出せないw

225 :デフォルトの名無しさん:2012/06/14(木) 11:03:22.93
まわりくどい言い回し、ほのめかし、あざけり
このスレの住人の得意技だね

226 :デフォルトの名無しさん:2012/06/14(木) 11:30:24.99
解決策ってなに?
アナライザに10000バイト表示されればいいの?

227 :デフォルトの名無しさん:2012/06/14(木) 12:02:36.32
>>226
すでに何人からか指摘があるけど、断片化が発生しないよう十分に小さなサイズでsendtoすること
もし大きなデータを送信したいのならアプリ側で分割/組み立て機能を実装する(TFTPのように)
IP層での断片化はRFCで仕様としては定義されているけど、その実装は必須ではないから環境依存

228 :デフォルトの名無しさん:2012/06/14(木) 12:07:03.04
PacMonだと最初の1パケットだけ見えて、Wiresharkだと何も見えないって
アナライザの使い方間違っているとしか思えないんだが

229 :デフォルトの名無しさん:2012/06/14(木) 12:08:50.04
UDP軽いらしい
・本読まない
・仕様はいわずもがな
・実装もしらない
・調べる気もない
・金を払うきもない


230 :デフォルトの名無しさん:2012/06/14(木) 12:15:52.07
>>223
10000バイト受け取った か 何も受け取らなかった の 2択ですしー

231 :デフォルトの名無しさん:2012/06/14(木) 12:16:53.78
IPフラグメンテーションを見たいなら、UDPじゃなくて
ICMP Echo(ping)で試してみれば良いのに。
WindowsでもLinuxでも10kバイトくらいなら何の問題もないが。

232 :デフォルトの名無しさん:2012/06/14(木) 12:32:32.97
>>231
いや、IPパケットの分割そのものはTCPで必須だから、どのアナライザでも見えるはずなんだよ
でも、「UDPデータグラムの分割(=断片化)」というのは常識的には想定されていないグレーゾーンだから、
アナライザ側での対応も解析可否を即答できる人はかなり限定されるんじゃまいかと
どうしても知りたいのならフリーならフォーラムへ有償ならベンダーへ問い合わせしたほうがいいと思う

自分なら最も素朴で実績のあるアナライザである、UNIX(Linux or Mac)のtcpdumpを使うけどね
最悪、-xオプションで全フレームを16進ダンプして自力で解析プログラムを組むことも考える

233 :229:2012/06/14(木) 14:27:54.70
追加
・パケットアナライザーも使えません

いうことありません

234 :デフォルトの名無しさん:2012/06/14(木) 20:10:26.38
>>210
昔、TCPサーバアプリを作る時に過去スレ全部見たな〜
おかげで初めて作ったTCPアプリだったが何年も何の問題もなく動いている。

235 :デフォルトの名無しさん:2012/06/14(木) 20:35:16.98
過去スレより、他の解説サイトやソース読めと思うのはオレだけだろうか

236 :デフォルトの名無しさん:2012/06/14(木) 20:48:20.36
>>232
IPフラグメントの話で、なんで上位層のTCPとかUDPとかが出てくるんだろう?

237 :デフォルトの名無しさん:2012/06/14(木) 21:06:58.41
>>236
何、言ってんのか、わからんのだけど

238 :デフォルトの名無しさん:2012/06/14(木) 21:36:05.26
>IPパケットの分割そのものはTCPで必須

この意味がわからん。

239 :デフォルトの名無しさん:2012/06/14(木) 22:09:52.82
>>235
このスレで紹介されているサイトや スティーヴンスの本も読んだよ。
ここは90%以上ゴミレスだけど時々神が降臨されるのさ。

240 :デフォルトの名無しさん:2012/06/14(木) 23:16:42.70
>>239
ソースは?

241 :デフォルトの名無しさん:2012/06/15(金) 00:51:01.82
>>180で答え出てるのに、何処まで混ぜっ返すんだよ。
>>181が馬鹿な回答するから、質問者を混乱させてるんじゃないか。

242 :デフォルトの名無しさん:2012/06/15(金) 01:17:59.73
それっぽいオプションがあるみたいだね
http://wiki.wireshark.org/IP_Reassembly

243 :デフォルトの名無しさん:2012/06/15(金) 01:26:17.48
TCPの送信段階で分割したような動作になってるだけでしょ
データを保証しないといけないからね
IPとして処理される段階ではMTUとかに合わせたサイズになっとる

244 :デフォルトの名無しさん:2012/06/15(金) 08:56:02.26
久々に伸びてると思ったら
何年も前の話がループしてるのか

245 :デフォルトの名無しさん:2012/06/15(金) 14:31:37.40
>>244
>>205
何年も前どころか二日前の話がループしている。

246 :デフォルトの名無しさん:2012/06/15(金) 17:34:02.50
>>243
> TCPの送信段階で分割したような動作になってるだけでしょ
> データを保証しないといけないからね

あのね、UDPの話で始まってるのよ。
状況とTCP/IPの仕様をちゃんと把握してないのに適当にレスする奴多すぎw
>>232とか斜めすぎて意味がわからん。

247 :デフォルトの名無しさん:2012/06/15(金) 18:04:05.68
tcp/ipスタック実装したことない人には何言ってもわからんかもね

248 :デフォルトの名無しさん:2012/06/15(金) 18:18:00.80
>>232はジョークだろ


249 :デフォルトの名無しさん:2012/06/15(金) 18:23:39.72
>>232
・IP層の断片化 (途中経路でも起きる。only IPv4)
・TCP層のセグメント分割 (peerのみで行われる)
を区別できてないだけ。
どちらもMTUが絡むから、初級者によくある混同で、それほど意味不明でもない。
ただしUDPについて推測で発言しているから、相当おかしい内容になってるけれども。

250 :デフォルトの名無しさん:2012/06/16(土) 17:25:18.62
実装依存な話でお互いが正義と主張してるだけに見えるな。

インターネットに流すならルータがめんどくさいなって思ったら容赦なく捨ててるから届かないって感じだ。
今はicmpで通知しても安物ブロードバンドルータが捨ててしまうからねえ。

送る側で小さくしてみてどのくらいなら通るって試行錯誤しながら送るしかない。ファイルベースなら512バイトずつ読んでるはずだから、512バイト読んでそのまま送ればいいんじゃ無い。
2セクタ読んで1024バイト送ってみてどのくらいパフォーマンス上がるかも環境次第だしねえ。

lteとかwimaxとかで帯域制限された/混雑時の送信ノウハウなんてのも必要なのかもしれない。128kbps制限とかされたらまず送ってもエラーだしね。

251 :デフォルトの名無しさん:2012/06/16(土) 17:30:18.32
アプリ層で小さくだの大きくだのして意味あんの?

252 :デフォルトの名無しさん:2012/06/16(土) 17:33:23.12
UDP使うんだと意味あるだろ

253 :デフォルトの名無しさん:2012/06/16(土) 17:40:39.59
>>250
そういう話じゃねーよ。>>181>>232は明らかに仕様を理解してない。

254 :デフォルトの名無しさん:2012/06/16(土) 19:27:39.93
>>250
バカの長文乙

255 :デフォルトの名無しさん:2012/06/16(土) 19:31:50.89
250は間違ってことは書いてないような

256 :デフォルトの名無しさん:2012/06/16(土) 19:35:34.91
お前も同類か

257 :デフォルトの名無しさん:2012/06/16(土) 19:40:30.38
UDPで落ちないようにがんばるくらいならTCP使えって事だわな

258 :デフォルトの名無しさん:2012/06/16(土) 19:40:35.09
本質わかってないのは、何作ってるんだろうね?
人に作ってもらって喜んでるガキレベルかもね

259 :デフォルトの名無しさん:2012/06/16(土) 21:26:02.57
>>258
本質ってなに? ちょっとここに書いてみて

260 :デフォルトの名無しさん:2012/06/16(土) 21:55:39.82
上から下まで、そしてまた上まで順を追って何をやってるか知れ。

261 :デフォルトの名無しさん:2012/06/16(土) 22:32:04.03
ブロック図とかながめて終わってる口かな
資料あっても必要なとこも探さない読めない系の人が増えてる?

262 :デフォルトの名無しさん:2012/06/16(土) 22:54:28.18
>>259
229,233

263 :デフォルトの名無しさん:2012/06/16(土) 23:19:49.73
TCP使ってもIPパケット断片化が原因の問題は起きうる。
(ill-functionalなhostは経路上にいないと仮定しても)
そしてTCPスタックが馬鹿だと、自分では解決しづらいことがある。

どういう時に起きうるかというと、
ルータの次の経路のMTUが極端に小さいのに、
fragmentationの実装は必須でないので実装してない場合。
(reassemblyの実装は必須)

まあ要するに十分小さいパケットを送っていれば気にする必要はない。
TCPスタックが行なっている解決方法は、
"Fragmentation Considered Harmful"を。
UDPプログラマはこの程度の内容は知っておくべき。
LAN内でしか使わないなら、なんちゃってプログラミングでいいと思うが。

264 :デフォルトの名無しさん:2012/06/16(土) 23:27:01.08
>>262
それがキミの考える「本質」なの?

265 :デフォルトの名無しさん:2012/06/16(土) 23:45:24.49
>>264
君の答えは?

266 :デフォルトの名無しさん:2012/06/16(土) 23:48:14.14
聞いておきながら自分が納得しないと怒ったり否定したりする愚者がいる
人に説明を求めて解答が常に得られると思っている蒙昧な者も多い

267 :262:2012/06/16(土) 23:52:49.67
仕様がわかんないのでどうしようもない

268 :デフォルトの名無しさん:2012/06/16(土) 23:56:16.24
    _, ,_  パーン
 ( ‘д‘)
  ⊂彡☆))Д´) >>267

269 :デフォルトの名無しさん:2012/06/17(日) 00:02:38.85
>本質わかってないのは、何作ってるんだろうね?

ここで言う「本質」が何を指しているかわからんから、この文自体が
何を言っているかわからないというだけだろ?
別に何か意味があるわけじゃなくて、なんとなくもっともらしい台詞を
書いただけなのかも知れんが。

270 :267:2012/06/17(日) 00:06:22.97
いたたた、なんでやねん

271 :デフォルトの名無しさん:2012/06/17(日) 00:06:24.02
俺は、本質わかってるだぜぇ。

って言いたいだけだろ。

ここまでのレスで内容が具体的に書かれてないところ見ると、本当かどうかは
かなり疑わしいから、普通にスルーでいいんじゃね?

272 :デフォルトの名無しさん:2012/06/17(日) 00:13:53.84
>>271
君は質問者か?

273 :デフォルトの名無しさん:2012/06/17(日) 00:20:41.17
具体的な内容書かれても理解できないからスルーしましたって話だね

274 :デフォルトの名無しさん:2012/06/17(日) 00:24:37.07
もしかして、一連の意味不明なレスはみんな>>181なんだろうか?

275 :デフォルトの名無しさん:2012/06/17(日) 00:25:28.46
>>273
そんな事は、その具体的なレス番を示してから言うことだよ。

276 :デフォルトの名無しさん:2012/06/17(日) 00:28:58.56
>>275
スルーしたレス番を示してみな?

277 :デフォルトの名無しさん:2012/06/17(日) 00:47:14.93
俺) 具体的な内容書いてるレスがない
>>273 理解できないからスルーしたんだろ
俺) 内容書いてあるレス番書きなよ
>>275 スルーしたレス番示せ

ひょっとして、馬鹿なの?

まあ、やっぱ脳内レスでしたというオチなんだろうな。

278 :デフォルトの名無しさん:2012/06/17(日) 00:55:55.40
>>277
スルーしたレス番を示してみな?

279 :デフォルトの名無しさん:2012/06/17(日) 01:55:08.65
結局それしか言えない訳ね。

それがわかれば十分、相手にした俺が馬鹿だったよ。

280 :デフォルトの名無しさん:2012/06/17(日) 03:52:26.83
今のnat前提インターネットでは当たり前になってるけど、なんでもかんでもtcpで送っとけば良いってのは違うと思うけどな。
udp要らないじゃない。

まあインターネットでudpで送ってもまず届かないから、lanやネットワーク管理者の管理下にある社内lan程度に留めとけってのは分かるけど。

281 :デフォルトの名無しさん:2012/06/17(日) 08:44:55.63
届く届かないとUDPかTCPかってのは関係ないだろ。
途中のreouterであえてUDPをブロックしたり優先度を下げているとかじゃなけりゃ。

282 :デフォルトの名無しさん:2012/06/17(日) 10:18:43.71
あいかわらず、馬鹿の突っ込み

283 :デフォルトの名無しさん:2012/06/17(日) 10:32:45.22
突っ込まれまくってる本人か?反論があるなら具体的に指摘してやれよ。

284 :デフォルトの名無しさん:2012/06/17(日) 10:35:48.73
いいや、馬鹿は馬鹿

285 :デフォルトの名無しさん:2012/06/17(日) 10:37:13.45
>>283
283=281?

286 :デフォルトの名無しさん:2012/06/17(日) 15:21:18.06
>>282
どのあたりが馬鹿なのか、解説してみろ。

287 :デフォルトの名無しさん:2012/06/17(日) 15:59:09.14
>>286
君のレス番は?

288 :デフォルトの名無しさん:2012/06/17(日) 16:14:10.70
>>287
>>281

289 :デフォルトの名無しさん:2012/06/17(日) 17:04:23.57
>>288
そこだけつっこんもしょうがねーだろ

馬鹿の壁

290 :デフォルトの名無しさん:2012/06/17(日) 17:20:45.61
じゃあ残りはお前が突っ込んでやれよ。
馬鹿にはできない突っ込みの手本というものを見せてくれ。

291 :デフォルトの名無しさん:2012/06/17(日) 17:37:32.28
なにこのグダグダな流れw

292 :デフォルトの名無しさん:2012/06/17(日) 17:42:04.99
元の質問者はまだいるのか?

293 :デフォルトの名無しさん:2012/06/17(日) 17:53:30.34
たぶん上でいろいろ突っ込まれていた奴が、反論できないけど
くやしいから何か言い返したくて「馬鹿」と言っているだけ。

294 :デフォルトの名無しさん:2012/06/17(日) 21:00:40.40
Linuxのプロトコルスタックの性能はどうなの?
昔はFreeBSDの方が1.1倍いいと言われていたが

295 :デフォルトの名無しさん:2012/06/17(日) 21:10:13.68
>>294
今はFreeBSDの1.2倍いい

ちなみにWindowsは33倍いい

296 :デフォルトの名無しさん:2012/06/17(日) 21:12:21.64
>>295
根拠はある?

297 :デフォルトの名無しさん:2012/06/18(月) 12:00:30.44
最近はプロトコルスタックの多くの部分がEthernetのチップ上で動いている@Windows

298 :デフォルトの名無しさん:2012/06/23(土) 22:14:47.79
ぶっとんだのか

299 :デフォルトの名無しさん:2012/07/17(火) 10:20:52.61
iocpで組む腕があるならwindowsでもいいかもな

300 :デフォルトの名無しさん:2012/07/20(金) 13:11:51.43
UDPホールパンチングの説明ってポートを開放していないクライアント同士の例ばっかりだけど、
ポートを開放しているPC-Aとポート未開放のPC-Bがあるとき、

1)B→Aに送信
2)Aは受信後、送信元(B)に送信
3)Bが受信

としたとき、2〜3番のA→BについてもUDPホールパンチングによって可能となった
と考えていいのかな?

301 :デフォルトの名無しさん:2012/07/20(金) 14:21:42.49
君がどう考えてもそれは自由だよ

302 :デフォルトの名無しさん:2012/07/20(金) 14:38:36.30
「2〜3番のA→Bについて『も』」と言っておるが、
(1)についてもUDPホールパンチングによって可能となったと考えているのか?

303 :デフォルトの名無しさん:2012/07/20(金) 14:57:51.74
まさか日本語の使い方についていちいち突っ込みくらうとは思わなかった
>>302
「も」は一般的に例に挙げられるポート未開放のクライアント同士の通信に対しての「も」だよ

304 :デフォルトの名無しさん:2012/07/20(金) 17:37:03.54
日本語のwikipediaじゃなくて英語のwikipediaを読むと良い。

> UDPホールパンチングの説明ってポートを開放していないクライアント同士の例ばっかりだけど、

でないことが分かる。


305 :デフォルトの名無しさん:2012/07/29(日) 23:11:40.41
無線APへ複数のAndroidを接続。Androidアプリ(Java)

IPMsgみたいなことをやりたくて、
1.A機種でServerSocketを待受て、AからUDP送信
2.B、C、D機種で受信
3.B、C、Dで受信したパケットオブジェクトから、Aのアドレスを取得して、
各機種からAのServerSocketめがけてTCP接続
 → エラー発生(することがある)

結果、
・B、C、Dすべてで、応答成功
・B、CはAへ応答を返せたのに、DでだけNo route to hostが出る
・Dは成功したが、B、CでNo ry〜

みたいな症状が出ています
タイミング的なもんか?とは思うんですが、なんかよくわからん

・No ry〜が出るときは、DからAへのpingコマンドでnetwork unreachable、
・AからDへpingすると、接続が回復する(ように見える。次回アプリ実行時にNo ry〜が出ない)
・Dからarp who-hasのブロードキャストが出ているが、Aで受信せず、B、Cでは受信できている

stackoverflow.comでAndroid + No route to hostって質問がいくつかあるけど、
結局解決してないように見える

なので、2chで解決するべ

306 :デフォルトの名無しさん:2012/07/31(火) 00:43:37.01
wireshark でみたら?

307 :デフォルトの名無しさん:2012/08/05(日) 11:23:49.49
ハッカー財閥 会長 トップは masa
ジャッチメント(規律委員)は全員しておくこと 1円でしておくこと
最新情報 大金をすべてしておくこと 
下に、無限超を数字にして、沢山書いて、数十枚、数百枚、数千万枚、数千京京京にして、銀行や松井証券など
に提出、FAXすればいいよ。上に京万枚と書いておくこと
最新情報 大金 
http://sky.geocities.jp/mannga9999/keizai2.txt
経営板で、アイスクリーム屋と、クリーニングの板見ればいい。
ほい。 
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
あとは、財閥の登記するだけ。kore
これノウハウ。教えていってたから、教えたおん。よ。
まーちゃんに、募金すること

突っ張りすぎて、中国の元が無価値になっぞ。実態のない経済は滅ぶ 今、元はマイナス。
http://blogs.yahoo.co.jp/mymymy90jp/2857425.html

これ改造して、大富豪ソフト作れない?金のレートが下がる時は、レートも下がるので、落ちる角度を計算してMその前にもどす機能があると、世界不況のときにも、できる。
http://www.vector.co.jp/soft/dl/win95/business/se312001.html
探せば、ソフトあるよ。瀬谷貴文が完成させている。
絶対命令
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
http://yuzuru.2ch.net/test/read.cgi/sakura/1158988790/
masaの分もやっておくこと 
depend on 銀行、matuisyouken monex
最後に、福祉財団、貧しい人を助ける財団をつくること
絶対命令 DC

308 :デフォルトの名無しさん:2012/08/05(日) 14:13:01.43
コピペマン参上!まで読んだ。

309 :デフォルトの名無しさん:2012/08/07(火) 11:42:50.66
sendtoとreceivetoでPC間でデータ受け渡ししてます(1回950バイト程度)
送信間隔は50msくらいなんですけどたまにパケットがロストします
特にsendtoはエラーを吐くわけでもなく普通に通信を続行してます
1時間に0から2回程度ロストする現象が起きます
このようなことはUDP通信では普通なのでしょうか?
なんとかロストしない方法があったら教えてください

310 :デフォルトの名無しさん:2012/08/07(火) 11:52:18.15
普通でしょう
ロストしたらもう一度送ればいいと思います

311 :デフォルトの名無しさん:2012/08/07(火) 12:17:29.49
IPv4 の仕様がよくわからんのですが
パケットヘッダのチェエクサムってのはルータを通るたびに変わるんですかい?
他にルータを経由してパケっどヘッダの中身で変わる可能性があるのは
Type of Service, TTL, Header Checksum, Option であってます?

312 :デフォルトの名無しさん:2012/08/07(火) 12:32:14.80
IPv4の仕様読めばすむ話だろ低脳

313 :デフォルトの名無しさん:2012/08/07(火) 12:50:16.33
>>309
UDPはロストするもんです嫌ならTCPを使いましょう。
1:1の通信でUDPを使うメリットは殆どないと思いますけど。

314 :デフォルトの名無しさん:2012/08/07(火) 12:58:17.65
>>313
ど素人がアドバイスするのは100年早いですよ。

315 :デフォルトの名無しさん:2012/08/07(火) 13:00:13.80
>>311
NATとかフラグメントとか考えれば
もっといろいろ書き変わるけど。

316 :デフォルトの名無しさん:2012/08/07(火) 13:00:39.69
あるだろ。バカ。
マルチキャスト/ブロードキャストよりユニキャストの方が圧倒的に
多く使われている。

317 :デフォルトの名無しさん:2012/08/07(火) 13:02:56.60
>>313
STREAMとDATAGRAMの差も理解できないバカですか?

318 :デフォルトの名無しさん:2012/08/07(火) 13:05:05.69
UDP(データグラムベース だけど、ロス有)
TCP(ストリームベース だけど、リトライ等である程度保障)
中間の SCTP ってのがあるけど… まだまだ普及してない印象

ある程度保障されたデータグラムのやり取り という用途は悩ましい
UDP でリトライ機構を考えるか, TCPでデータグラム単位に切り出す機構を考えるか

319 :デフォルトの名無しさん:2012/08/07(火) 13:08:55.69
>>309もド素人だから、
>>313の一行目はいいと思う。
2行目は間違い。

320 :デフォルトの名無しさん:2012/08/07(火) 13:10:46.78
使う必要ないところでUDP使って勝手に泥沼に嵌る奴が多すぎて笑える

321 :デフォルトの名無しさん:2012/08/07(火) 13:12:24.73
>>319
いいえ、50ms間隔で送信という要件が出てきた時点で
TCPが候補に挙がることはあり得ません。
1行目も誤りです。TCPの再送機構にだけ目が行き、
それによってどのようなパケットフローになるかがまったく
考慮されていません。

322 :デフォルトの名無しさん:2012/08/07(火) 13:14:44.08
>>315
逆に言うと
そのあたりがなければTOSとTTLくらいってことですか
ありがとうございました。

323 :デフォルトの名無しさん:2012/08/07(火) 13:17:53.52
無知どうしで罵りあいわろた
全く解決できてないしw

324 :デフォルトの名無しさん:2012/08/07(火) 13:18:27.96
>>321
PSHフラグあるがな。

325 :デフォルトの名無しさん:2012/08/07(火) 13:18:40.66
50msってどんだけ長い時間だか分かってる?www

326 :デフォルトの名無しさん:2012/08/07(火) 13:19:24.85
>>323
> なんとかロストしない方法があったら教えてください

そりゃこれが直結しない限り解決不能だし。

327 :デフォルトの名無しさん:2012/08/07(火) 13:26:23.22
50msを長いと思ってしまっている人がシステムを設計すると
すごい結果が待ってる気がするw

328 :デフォルトの名無しさん:2012/08/07(火) 13:26:27.33
直結でも同じなんだけどな

329 :デフォルトの名無しさん:2012/08/07(火) 13:29:51.94
どんな環境(OS、ネットワーク)なのか、50ms毎に送信するデータサイズが何も書かれてないのでアレだけど
50msがTCPじゃだめでUDPならOKという判断がどこから出てくるのかと



330 :デフォルトの名無しさん:2012/08/07(火) 13:31:20.43
しかも
> なんとかロストしない方法があったら教えてください
の要件で

331 :309:2012/08/07(火) 13:31:25.94
書き間違えてすみませんが実際は20msごとに950バイトのデータを送信します
直結でやってますけど1時間に1回くらいでる頻度を
3時間に1回とかもっと頻度を減らすことは無理ですか?


332 :デフォルトの名無しさん:2012/08/07(火) 13:31:55.82
>>309
回線上ではロストしていないことが前提だけど
SO_RCVBUFとSO_SNDBUFを増やしてみては?

333 :デフォルトの名無しさん:2012/08/07(火) 13:32:30.84
> sendtoとreceivetoでPC間でデータ受け渡ししてます(1回950バイト程度)
データサイズがわからないメクラはレス禁止

334 :デフォルトの名無しさん:2012/08/07(火) 13:34:20.77
>>331
OS、ネットワークHW、ドライバを厳選すれば頻度を下げることは不可能ではない

335 :デフォルトの名無しさん:2012/08/07(火) 13:35:20.80
どこで消えてるか調べるのが先でないかい?

336 :デフォルトの名無しさん:2012/08/07(火) 13:41:01.26
1パケット/50msか 楽でいいなあ

337 :デフォルトの名無しさん:2012/08/07(火) 13:41:39.85
>>324
PSHの作用としては正しいけど、そういう使い方をするものじゃないよ。

338 :309:2012/08/07(火) 13:42:36.82
色々ありがとう
使ったことないけどパケットキャプチャソフト使って監視して
ちゃんと受けてるのに消えてるならバッファ容量増やすってことですね
ちょっとやってみます

339 :デフォルトの名無しさん:2012/08/07(火) 13:44:01.94
いや、どんだけ頑張ってもロストするから

340 :デフォルトの名無しさん:2012/08/07(火) 13:44:45.46
>>338
netstat

341 :デフォルトの名無しさん:2012/08/07(火) 13:45:23.36
1パケット/50msでロストするのは明らかにバッファサイズのせいじゃないし

342 :デフォルトの名無しさん:2012/08/07(火) 13:45:51.47
>>331
以下のような、定遅延で高品質なシステムを設計すれば可能かもしれない
・リアルタイムOSを採用して、通信プロセスが途中でスイッチされない優先度を設定する
・コンピュータとネットワーク全体を電磁シールドで包み込む

それが無理なら、素直に>>313が言うようにTCPを採用しなさい

343 :デフォルトの名無しさん:2012/08/07(火) 13:46:05.06
専用バスで直結するとかでなければ
100%ロストしない環境は構築できないよ。
SATAやPCIEですらパケットロスがあるんだぜ?

344 :デフォルトの名無しさん:2012/08/07(火) 13:46:34.10
>>314
分かりました100年後にまたレスします

345 :デフォルトの名無しさん:2012/08/07(火) 13:48:18.45
>>341
50ms間隔で刈り取れることを前提にバッファサイズが950バイトに
なってるかもしれんw

346 :デフォルトの名無しさん:2012/08/07(火) 13:49:09.66
1kバイト/20msなら2,3個送って重複したの捨てればいいじゃん。

347 :デフォルトの名無しさん:2012/08/07(火) 13:50:59.88
>>331
20msごとに950バイトのデータを送信って何に使うのですか?
しかもロストしないのが前提って。

348 :デフォルトの名無しさん:2012/08/07(火) 13:53:07.95
ハード屋さんはUDP使いたがるけどソフト屋さんはTCPが好きw

349 :デフォルトの名無しさん:2012/08/07(火) 13:53:47.93
>>347
不明な用途では回答できないなら引っ込んでなよ。

350 :デフォルトの名無しさん:2012/08/07(火) 13:55:27.97
>>339
良いこと言った

351 :デフォルトの名無しさん:2012/08/07(火) 13:57:18.36
ロストを減らしたいってんでしょ
よく読まないメクラが多いな

352 :デフォルトの名無しさん:2012/08/07(火) 13:58:29.35
1時間に1つは駄目で3時間に1つなら良いとは・・・

353 :デフォルトの名無しさん:2012/08/07(火) 13:59:34.79
仕様に文句言ってしょうがない

354 :デフォルトの名無しさん:2012/08/07(火) 14:00:33.13
一番重要な事は伏せられたままである。

355 :デフォルトの名無しさん:2012/08/07(火) 14:05:04.32
>>321
1時間に1,2回再送するだけじゃないのよ?

356 :342:2012/08/07(火) 14:07:31.25
>>321
ん?50msという定数を速い or 遅い、どちらで判断しているのかな?
こういった定数は前提環境によって基準が変わるから、まずそれを明確にしてほしいね

自分としては、>>309に「信頼性のある(=ロストしない)通信」という要件が出てきた時点で、
第一候補としてTCPを選ぶよ
どうしてもUDP上の独自プロトコルを設計する価値のある極めて限られたケースであれば、
ようやくUDP選択を検討し始める

>>344
馬鹿のつまらんヤジはスルー汁!!



357 :デフォルトの名無しさん:2012/08/07(火) 14:11:08.13
IP接続にリアルタイム性を求めても無理ですよ。

358 :309:2012/08/07(火) 14:14:26.91
さっそくしらべてみました。
Microsoft Network Monitor3.4で受信側PCを監視したら
パケットが届いていませんでした
これは完全にロストってことでどうしようもないですか?
まだロスト率下げる手とかあるんでしょうか?
余りプログラムを触りたくないのでUDPでやりたいんです

359 :デフォルトの名無しさん:2012/08/07(火) 14:17:39.10
>>358
再送ロジックを実装汁よ。

360 :デフォルトの名無しさん:2012/08/07(火) 14:18:09.64
またまたまたまた、この手のレベルの意味の無い言い合いが始まっちゃった

361 :デフォルトの名無しさん:2012/08/07(火) 14:19:52.34
さっそく調べてみてこれだけの時間でロストが判明するなら、
1パケット/1時間より高頻度で発生してるって事じゃん。

362 :デフォルトの名無しさん:2012/08/07(火) 14:21:13.33
夏休みの学生の釣りでしょう

363 :デフォルトの名無しさん:2012/08/07(火) 14:23:03.78
>>356 が言うようにロスト不可な時点でUDPの選択肢はない。


364 :デフォルトの名無しさん:2012/08/07(火) 14:23:48.74
再送ロジックといっても送り側はエラーも検出できないし
相手からの応答処理とかいろいろ追加してたら20msでの送信も難しくなるし
ロストは仕方ないとして頻度を減らすいいてがあれば…

365 :342:2012/08/07(火) 14:30:48.72
>>358,364
まだ言ってるかwww

(>>358) >まだロスト率下げる手とかあるんでしょうか?
(>>364) >ロストは仕方ないとして頻度を減らすいいてがあれば…

>>334,342を嫁

>余りプログラムを触りたくないのでUDPでやりたいんです

前段の手段なら完全にハードウェアの話だから、プログラムは無変更で対応できる「かも」しれない
それが嫌なら、素直にTCPを使いなさい

>>359
プログラムをUDPベースからTCPベースへ書き換えるコストと
UDP上の独自プロトコルに再送ロジックを追加実装するコストを比較汁!!

366 :デフォルトの名無しさん:2012/08/07(火) 14:31:04.76
>>364
無いでしょう。
直結ならRS-232C/422で良いのでは。

367 :デフォルトの名無しさん:2012/08/07(火) 14:35:55.04
RS-232Cじゃ速度的に無理だったw

368 :デフォルトの名無しさん:2012/08/07(火) 14:40:04.60
受信側がなにを期待しているか次第だな。
やみくもにTCP勧めてるのは宗教家か何かだな。

369 :デフォルトの名無しさん:2012/08/07(火) 14:43:34.88
TCPの再送制御がどういうものか理解してTCPを使うならいいと思うけど、
TCPはロスが続いた時の復旧がね。
個人的には再送制御を簡単に入れ込んだUDPのほうがおすすめ。

370 :デフォルトの名無しさん:2012/08/07(火) 14:45:48.84
TCPで再送云々になるならUDPで入れ込んでも一緒では?

371 :デフォルトの名無しさん:2012/08/07(火) 14:46:16.08
>>368
アナログ的なデータならロストしたところを前後値から補完すればよさそうだしね。
用途が分からなきゃアドバイスもできない。

>>369
TCPの再発明にならなきゃ良いけど

372 :デフォルトの名無しさん:2012/08/07(火) 14:46:36.35
再送はいらないけど抜けを少なくしたい、というのがね
環境によるだろうし今うまく行ってもあとで困るかもだし。
連番入れて抜けたらそこからやり直してもらう、とかでいいんじゃ?

373 :デフォルトの名無しさん:2012/08/07(火) 14:48:41.72
>>369
20ms間隔で1時間送って1,2個のロスでしょ。
殆どACK応答で再送なんかないでしょ。

374 :デフォルトの名無しさん:2012/08/07(火) 14:49:01.13
>>370
TCPはロスが続くとどんどん再送時間が長くなるんだよ。
ストリームだからその間データは送れないしね。
物理的に復旧してから再送時間の満了までが無駄。
順序性保証との兼ね合いだけど、UDPでガンガン送り続けて
届かなかった分だけ再送で送りなおしてもらうほうが俺の好み。

375 :デフォルトの名無しさん:2012/08/07(火) 14:51:20.99
そんなの作りこんでたら管理するデータが増えまくって無駄。

376 :デフォルトの名無しさん:2012/08/07(火) 14:51:28.13
>>373
1時間で1,2個のロスしか絶対にしないことが保証されているならね。
何用のプログラムか知らないけど、それが保証されているならいいけど、
俺は、何かの実運用に使われることを想定してケーブル抜けとかそういう
のを考慮してUDPを推してる。

377 :デフォルトの名無しさん:2012/08/07(火) 14:53:34.45
>>375
そうでもないよ?
TCP並みにやろうとするとすごいことになるけど、
オリジナルの簡単な再送ロジックとか作っておくと、いろいろ使いまわせるよ。

378 :309:2012/08/07(火) 14:55:30.76
色々すみません
厳密に言うと今は直結もどきなので本当のクロス直結でやってみます
これでロスが減るとうれしいんですが…
ちなみに現状の構成はこうなっています。
スイッチングハブだから直結と同じかと思ってますが違うのですかね?

PC(送信)---スイッチングハブ---PC(受信)
         |
         モニタ用PC---(無線)---ルータ---(インターネット)

これを、以下のようにしてやってみます
PC(送信)---PC(受信)

379 :デフォルトの名無しさん:2012/08/07(火) 14:56:17.68
余りプログラムを触りたくないと言う人に作りこめって本末転倒?

380 :デフォルトの名無しさん:2012/08/07(火) 14:56:22.16
>>376
一方的にTCPで送ってTCPのエラーが返ってくるまでだと接続断検知まで
何分も待たされるけどね。普通は相手側からなんらかの応答が返るような上位プロトコルに
するでしょうし。

381 :デフォルトの名無しさん:2012/08/07(火) 14:58:41.89
>>378
スイッチングハブって他のPCのパケットモニターできるの?

382 :デフォルトの名無しさん:2012/08/07(火) 15:00:23.42
パケットモニター?

383 :デフォルトの名無しさん:2012/08/07(火) 15:00:43.31
>>379
TCPにするにしても、それなりに手が入るんだから
まあどっちにせよがんばれってことで。

384 :デフォルトの名無しさん:2012/08/07(火) 15:02:04.95
>>381
ミラーポートの設定ができる、高い奴ならば。

385 :デフォルトの名無しさん:2012/08/07(火) 15:02:50.88
>>381
まぎらわしい書き方しましたがモニタPCとは受信側PCの受信プログラムを
コンパイルして受信PCに共有フォルダで送るだけのPCです
パケットモニタは受信側PCにMicrosoftのモニタソフトを入れて直接みました

386 :デフォルトの名無しさん:2012/08/07(火) 15:04:00.60
相手局もPCで それぞれのコードに手出しできるなら良いよなぁ

PC vs 三菱のPLC で、プロトコルは相手側の事情で固定ってモデルで泣いた

387 :デフォルトの名無しさん:2012/08/07(火) 15:08:19.07
外野がいろんなパターンを想定してあーだこーだ言っているのに
相変わらずマイペースで何が求められているかも明かさないレス主。

388 :デフォルトの名無しさん:2012/08/07(火) 15:10:15.75
嫌なら見るな

389 :デフォルトの名無しさん:2012/08/07(火) 15:11:49.83
>>378
最初の質問から空想してたネットワーク構成と全然違ってびっくりしたW

390 :デフォルトの名無しさん:2012/08/07(火) 15:12:46.50
>>386
MXコンポーネント使わなかったのか

391 :デフォルトの名無しさん:2012/08/07(火) 15:13:28.85
>>387
学生さんにそんなこと要求しても

392 :デフォルトの名無しさん:2012/08/07(火) 15:14:00.13
>>389
全然違うってほど違わないだろ
スイッチングハブなんだからいらないパケットは通らないだろうし
直通と一緒じゃね

393 :デフォルトの名無しさん:2012/08/07(火) 15:14:13.96
>>390
うむす。 MCプロトコルを直接おしゃべりしたよ

394 :デフォルトの名無しさん:2012/08/07(火) 15:16:55.88
>>393
それは泣けるお話だな。いや、良く実装したもんだw

395 :デフォルトの名無しさん:2012/08/07(火) 15:17:37.64
ポートミラーリング設定しても100%ミラーできるわけじゃないしなあ…

396 :デフォルトの名無しさん:2012/08/07(火) 15:22:04.58
スイッチングハブがぼろいと輻輳が起きてパケット消えるかもね
直接続ならそれが起きる可能性ないからいけるかもな

397 :デフォルトの名無しさん:2012/08/07(火) 15:55:08.10
>>392
まあロスト率が倍になる程度かもね

398 :309:2012/08/07(火) 16:00:02.12
クロス直結で1時間以上何もロストしてません
ハブかケーブルが原因だったようですね
このまま、ロストせずに長時間継続できたら解決です
ありがとうございました

399 :デフォルトの名無しさん:2012/08/07(火) 16:07:28.61
まだこんなことやってんの

て解決したか

400 :326:2012/08/07(火) 16:23:08.60



401 :デフォルトの名無しさん:2012/08/07(火) 16:26:06.10


402 :デフォルトの名無しさん:2012/08/07(火) 16:27:22.38
今後クロス直結で運用することで解決か

403 :326:2012/08/07(火) 16:31:24.21
いまどきクロスもストレートもないけどなw

404 :デフォルトの名無しさん:2012/08/07(火) 16:34:54.44
長時間試験した上で自分の責任で保証するしかない
誰も保証してくれないから

405 :デフォルトの名無しさん:2012/08/07(火) 16:35:23.39
直結はクロスのみです
未だにストレートおkになっていないはず

406 :326:2012/08/07(火) 16:41:36.64
いまどきクロス/ストレート接続自動判別機能なしのスイッチ探す方が難しい。

407 :デフォルトの名無しさん:2012/08/07(火) 16:44:53.94
PC-PC直結で、間にハブが居ない話ですので
PCのIFカード側にクロス/ストレート接続自動判別機能が居るか?が焦点かと。

408 :デフォルトの名無しさん:2012/08/07(火) 16:51:52.50
>>405
1000Base-Tなら、Auto-MDIは必須です。

409 :デフォルトの名無しさん:2012/08/07(火) 16:57:56.58
>>408
1000Base-Tなんて誰も言ってないだろアフォ

410 :デフォルトの名無しさん:2012/08/07(火) 17:18:50.89
>>406
そうそう。すごい苦労したわ。

411 :デフォルトの名無しさん:2012/08/07(火) 17:58:39.72
自動じゃない奴なんて皆無に近い。PCも同じ。
逆に知らない奴はわざわざクロス探すか作ってたのか?

412 :デフォルトの名無しさん:2012/08/07(火) 18:03:38.58
うちのサーバ機、オートのやつなんて皆無だが

413 :デフォルトの名無しさん:2012/08/07(火) 18:46:33.24
ふつう、クロスアダプタくらい机の中に入れてるだろ

414 :デフォルトの名無しさん:2012/08/07(火) 18:52:15.95
サーバーでGbEじゃないのって骨董品だろ。

415 :デフォルトの名無しさん:2012/08/07(火) 19:08:17.96
リピータハブを買うのも苦労する時代だし仕方ない

416 :デフォルトの名無しさん:2012/08/07(火) 19:11:51.40
一日で100レス伸びてるんだが何があった
ム板屈指の超人気スレみたいじゃないか

417 :デフォルトの名無しさん:2012/08/07(火) 20:01:08.94
そもそも、20msの処理なんてWindowsでは無理ポなのだが

418 :デフォルトの名無しさん:2012/08/07(火) 20:20:54.01
久々の大漁

419 :デフォルトの名無しさん:2012/08/07(火) 20:37:40.91
>>417
コンピュータなんてナノで動いてるのに無知だな
100マイクロの制御プログラムとか何年も前に造ったことあるよ

420 :デフォルトの名無しさん:2012/08/07(火) 20:38:47.62
>>419
Windowsで?

421 :デフォルトの名無しさん:2012/08/07(火) 20:47:00.44
>>420
もち

422 :デフォルトの名無しさん:2012/08/07(火) 20:50:26.23
>>421
へぇ〜、Windowsでそんな応答時間が保証されるんだ。。

423 :デフォルトの名無しさん:2012/08/07(火) 20:53:21.22
パフォーマンスカウンタなら1ms以下の精度

424 :デフォルトの名無しさん:2012/08/07(火) 20:58:54.40
1ms守ればいい ってのならWindowsの方が気楽に書けるね

425 :デフォルトの名無しさん:2012/08/07(火) 20:59:27.48
WindowsってリアルタイムOSじゃないっぺよ〜

426 :デフォルトの名無しさん:2012/08/07(火) 21:00:17.40
>>425
リアルタイムOS の定義知ってる?

427 :デフォルトの名無しさん:2012/08/07(火) 21:00:24.55
Windowsの応答保証って25msくらいじゃないのさ?

428 :デフォルトの名無しさん:2012/08/07(火) 21:02:25.21
WindowsはRTOSじゃないから、他のタスクが走っていて忙しい時には
保証するのは無理だろう。
当然、TCPでは無理だけどUDPなら大丈夫、という状況にはならないはず。

で、timeBeginPeriodかなんかで、20msより短くすれば
「CPUが忙しくなければ20ms以下の間隔で処理できる可能性が高い」くらいにはできるだろう。
当然だけど、TCPならばnagleも無効にしておく必要がある。

429 :デフォルトの名無しさん:2012/08/07(火) 21:03:10.78
最近のマザーボードは、CPUクロックを動的に変更するからな。
パフォーマンスカウンタ信用できんだろ

430 :デフォルトの名無しさん:2012/08/07(火) 21:04:58.01
RealtimeOS上で動くWindowsってのもあるんだぜ
勉強になったな

431 :デフォルトの名無しさん:2012/08/07(火) 21:05:43.64
CPUクロックの変更と、タイマは関係ない。
タイマは、割り込みを発生させる、変動の少ないもののはず。

432 :デフォルトの名無しさん:2012/08/07(火) 21:08:28.81
>>430
いくらすんの?

433 :デフォルトの名無しさん:2012/08/07(火) 21:12:52.38
>>430
超マイナーじゃないですか。

434 :デフォルトの名無しさん:2012/08/07(火) 21:46:29.40
>>430
そのWindowsはリアルタイムOSなのか?

435 :デフォルトの名無しさん:2012/08/07(火) 22:56:58.73
RealtimeOSの意味が分かっていないのだから、そってしといてやれ

436 :デフォルトの名無しさん:2012/08/07(火) 23:03:41.62
標準的なネットワーク(今だと1000BASE?)のレイテンシと
標準的なディスクのレイテンシって
今だとどちらも数msくらいで同等だけど、以前はどうだったんだろう?
ネットワーク速度の進化の遅さを考えると、昔はもっと差があったのかな

437 :デフォルトの名無しさん:2012/08/07(火) 23:24:24.16
どうでもいいじゃないかそんな事

438 :デフォルトの名無しさん:2012/08/07(火) 23:35:12.75
>>434
リアルタイムOS上の仮想環境でWindowsが動いて
リアルタイム処理が必要な場合は本体側のOSを使う製品が昔合ったな。
今もあるかどうかは知らないけれど当時100万くらいしたはず。

439 :デフォルトの名無しさん:2012/08/07(火) 23:46:01.21
>>438
今もあるよ。
http://www.mnc.co.jp/intime/

440 :デフォルトの名無しさん:2012/08/07(火) 23:52:22.90
すげーな
50μで動かせるのか

441 :デフォルトの名無しさん:2012/08/08(水) 01:02:44.91
pingで負荷試験もどきとかやらないのかね?

442 :デフォルトの名無しさん:2012/08/08(水) 01:50:54.83
>>441
そんなんで何の負荷試験ができるのだ?

443 :デフォルトの名無しさん:2012/08/08(水) 02:16:15.64
なんでやらないんだ?

444 :デフォルトの名無しさん:2012/08/08(水) 03:00:19.10
>>442
NICへの高負荷

445 :デフォルトの名無しさん:2012/08/08(水) 07:05:09.96
>>444
pingで?

446 :デフォルトの名無しさん:2012/08/08(水) 10:02:08.29
>>445
ショートパケットは負荷高い

447 :デフォルトの名無しさん:2012/08/08(水) 10:29:59.44
>>446
1パケット/1秒で? 負荷高い?

448 :デフォルトの名無しさん:2012/08/08(水) 10:40:29.84
日本だとハッキング扱いされて逮捕されるぐらいには負荷高い

449 :デフォルトの名無しさん:2012/08/08(水) 10:59:17.31
日本だとpingが不正アクセスになる

450 :デフォルトの名無しさん:2012/08/08(水) 11:10:56.46
ダウンロードしただけで逮捕

451 :デフォルトの名無しさん:2012/08/08(水) 11:12:25.85
>>448
DOSアタックってどんな容疑で逮捕?

452 :デフォルトの名無しさん:2012/08/08(水) 11:13:10.67
>>450
○○なものをダウソするとでしょう

453 :デフォルトの名無しさん:2012/08/08(水) 11:21:01.63
>>451
岡崎図書館事件で検索

454 :デフォルトの名無しさん:2012/08/08(水) 11:40:41.58
大抵は不正アクセス禁止法違反でしょっ引けるからな
一旦しょっ引いたら監禁して自白強要の力技で終了

455 :デフォルトの名無しさん:2012/08/08(水) 11:48:38.95
不正アクセス禁止法違反って、パスワードなどのアクセス制御を突破したり回避したりしなきゃ成立しないんじゃない
DoS攻撃はアクセス制御を回避する必要なんか微塵もないから、ただの業務妨害なんじゃない

456 :デフォルトの名無しさん:2012/08/08(水) 11:52:13.10
まあとりあえず逮捕するんじゃないかな

457 :デフォルトの名無しさん:2012/08/08(水) 11:57:30.08
とりあえず逮捕して、すったもんだのあげく訴えた側に非があったことに気づいても
体裁のために取り下げできないんだよな。

458 :デフォルトの名無しさん:2012/08/08(水) 12:23:27.32
金子氏がどうなってしまったか


459 :デフォルトの名無しさん:2012/08/08(水) 12:24:31.23
それどこの岡崎図書館事件

460 :デフォルトの名無しさん:2012/08/08(水) 12:47:57.92
>>453
そりゃTCP TIME_WAIT が溜まって?サーバに接続不能になった
おそまつ過ぎるサーバアプリに原因があったのでは

461 :デフォルトの名無しさん:2012/08/08(水) 13:01:32.98
その脆弱性を突こうとするのは不正アクセスと看做せる
故意か過失は当人にしか分からない、という事は取り調べでどうにでも出来るという事

462 :デフォルトの名無しさん:2012/08/08(水) 13:02:06.26
>>460
1パケット/1秒のpingで高負荷試験している>>444のサーバに攻撃したら楽勝で逮捕。

463 :デフォルトの名無しさん:2012/08/08(水) 13:07:35.04
不当逮捕は警察も罰せられるべきなんだけどなー

464 :デフォルトの名無しさん:2012/08/08(水) 13:09:00.66
ゲイツ砲でurl間違えたら即逮捕だな

465 :デフォルトの名無しさん:2012/08/08(水) 13:12:28.98
>>447
フラッドオプションでググれ

466 :デフォルトの名無しさん:2012/08/08(水) 13:14:46.19
まあflood攻撃はインフラ設計時の話であって
プログラミングにはあまり影響はないけど
知らないってのはヤバイ

467 :デフォルトの名無しさん:2012/08/08(水) 13:32:43.22
>>466
1時間に400アクセスで落ちる某図書館のシステムを作ったSEは?

468 :デフォルトの名無しさん:2012/08/08(水) 13:35:58.04
まあ図書館のシステムとかど素人が作ってそうなイメージだなw
データつっこんで検索するだけだもんなw

469 :デフォルトの名無しさん:2012/08/08(水) 13:43:29.04
まあDBの基本だしな

470 :デフォルトの名無しさん:2012/08/08(水) 14:22:36.42
>>467
三菱なんとかってとこだったかな

471 :デフォルトの名無しさん:2012/08/08(水) 15:14:29.87
C++やC#でネットワークプログラム作れますか?

472 :デフォルトの名無しさん:2012/08/08(水) 15:15:39.44
何でその2つなのかわからんけど作れるよ、内容によるけど

473 :デフォルトの名無しさん:2012/08/08(水) 15:18:42.77
Javaにしとけ

474 :デフォルトの名無しさん:2012/08/08(水) 16:23:44.84
>>471
>ネットワークプログラム
ワームか

475 :デフォルトの名無しさん:2012/08/08(水) 22:05:21.21
C++でMMO作ってるよ

476 :デフォルトの名無しさん:2012/08/09(木) 00:09:51.99
>>471
作れない

477 :デフォルトの名無しさん:2012/08/09(木) 00:38:10.22
ネットワークプログラムって単語で語りたいだけじゃね

478 :デフォルトの名無しさん:2012/08/09(木) 10:38:49.27
boostのネットワークって作りこみ甘いよね

479 :デフォルトの名無しさん:2012/08/09(木) 10:49:39.77
ネットワークプログラミング入門したいのですが何からやるべきなのかとんと見当がつきません
いい入門書はないでしょうか?オライリーの体で覚えるネットワークとか評判いいですけどどうなんでしょう?

480 :デフォルトの名無しさん:2012/08/09(木) 11:19:15.45
まずはケーブル作りからじゃないか

481 :デフォルトの名無しさん:2012/08/09(木) 11:39:35.04
>>479
スティーヴンスの遺作を読め

482 :デフォルトの名無しさん:2012/08/09(木) 11:45:39.89
>>479
知ったかぶりする知識をつけるには良い本だと思うが駄本の香りがするし
そもそもプログラミングの本ではないでしょう。

483 :482:2012/08/09(木) 11:49:47.06
>>479
>>3-4 見れ

484 :デフォルトの名無しさん:2012/08/09(木) 11:51:10.22
猫でもシリーズは除外だ

485 :デフォルトの名無しさん:2012/08/09(木) 12:59:43.38
イーサーネットプログラミングといえばTCPIPプログラミングのことでしょうか?
イーサーネットでファイルを送りたいときの一般的なプログラミングとかあったら教えてください
TCPIPプログラミングだとは思うのですが経験がないのでよくわかりません

486 :デフォルトの名無しさん:2012/08/09(木) 13:05:20.06
イーサーネットプログラミングはイーサーネットをコントロールするプログラムであり一般的にはドライバの部類ですのでファイルを送るなどは関係ありません

487 :デフォルトの名無しさん:2012/08/09(木) 13:13:35.35
>>485
先ずは通信プロトコルからお勉強してください。

488 :デフォルトの名無しさん:2012/08/09(木) 13:15:35.07
TCP/IPはイーサーネットより上の層

489 :デフォルトの名無しさん:2012/08/09(木) 13:26:41.03
ネットワーク層以下を触るようなプログラムなんてそうそうあるんですか?
VPNサービス作るならデータリンク層触らないといけないとかは聞いたことありますが

490 :デフォルトの名無しさん:2012/08/09(木) 13:31:48.99
VPNだってほとんどがover IPの時代。

491 :デフォルトの名無しさん:2012/08/09(木) 13:38:46.95
シリアル通信

492 :デフォルトの名無しさん:2012/08/09(木) 14:23:15.00
確かにシリアル通信はだいたい物理層の直上で作業するな
つーか2〜6層がごっそり抜けていきなりアプリケーション層だよな

493 :デフォルトの名無しさん:2012/08/09(木) 14:40:45.90
>>485
電気信号にプログラムをデコード・エンコードするのは結構難しい

494 :デフォルトの名無しさん:2012/08/09(木) 15:41:24.65
パイソンで入門するとわかりやすい

495 :デフォルトの名無しさん:2012/08/09(木) 16:01:05.15
>>493
>電気信号にプログラムをデコード・エンコードするのは結構難しい

それは物理層の責務だよ
そして、>>485の言うイーサネットはデータリンク層のプロトコルだ
素人はネットワークアーキテクチャから勉強し直しなさい
--> http://ja.wikipedia.org/wiki/OSI参照モデル

496 :デフォルトの名無しさん:2012/08/09(木) 16:49:21.80
こういうめんどくさい人が、このスレから消えますように

497 :デフォルトの名無しさん:2012/08/09(木) 16:56:38.77
>>495
汎用IFで直接信号コントロールする場合もあるんだよ。

498 :デフォルトの名無しさん:2012/08/09(木) 16:57:14.13
ISOのOSIを知っていても実際は余り役には立たないな。
OSIは後付け理論なので実際とは合っていない。

499 :デフォルトの名無しさん:2012/08/09(木) 16:59:03.39
>>497
釈迦や孔子が生きていた時代の話ですね。

500 :デフォルトの名無しさん:2012/08/09(木) 17:05:25.45
>>499
でもたまーに今でも「手動で232c受信」をやることがあるよ!
助けて!

501 :デフォルトの名無しさん:2012/08/09(木) 17:20:02.63
>>498
RFC読んだら分かるが、OSI参照モデルは既に常識になってる。
プロトコル階層をまたいだり、逆転したりする場合にも、
OSI参照モデルの言葉でそれが説明されてる。

OSIで死んだのはプロトコル群。CLNSとか。
ASN.1みたいにLDAPの中で生き残ってるエンコーディング方式もある。

502 :デフォルトの名無しさん:2012/08/09(木) 17:22:56.80
>>500
UART買えないほど貧乏なのですか

503 :デフォルトの名無しさん:2012/08/09(木) 18:30:11.88
>>502
基板を作り直すお金が無いほど貧乏

504 :デフォルトの名無しさん:2012/08/09(木) 21:01:27.69
トークンリングてまだ動いているのかな

505 :デフォルトの名無しさん:2012/08/09(木) 21:41:54.78
>>503
ソフト実装で38.4Kbps出せたら神認定で良いのか?

506 :デフォルトの名無しさん:2012/08/09(木) 21:45:23.01
>>495
プログラムをデコード・エンコードつうのもよくわからん話だが
物理層の仕事はデータ(ビット情報)と電気信号との変換
そのデータがプログラムなのかどうかなんて関係ない
ま、>>495本人は解ってるだろうけど

>>485
とりあえずTCP/IPだけ勉強しとけば、そのへんは必要ならそのうち解る
必要ないなら解らなくても困らない

507 :デフォルトの名無しさん:2012/08/09(木) 21:56:25.12
>>506
馬鹿乙

508 :デフォルトの名無しさん:2012/08/09(木) 22:02:58.01
>>507
低脳乙

509 :デフォルトの名無しさん:2012/08/09(木) 22:07:17.41
>>508
はじめまして馬鹿

510 :デフォルトの名無しさん:2012/08/09(木) 22:10:47.48
>>509
池沼乙

511 :デフォルトの名無しさん:2012/08/09(木) 22:17:48.50
>>510
506=495

512 :デフォルトの名無しさん:2012/08/09(木) 22:21:55.39
とりあえず入門者はTCP/IPからでいいんですか?
ハードウェアの知識どころかOSの知識もほとんどないんですがそんなんでやって行けるんでしょうか
標準C/C++のコードが書けるだの能力しかありません

513 :デフォルトの名無しさん:2012/08/09(木) 22:23:59.78
右を向いても左を見ても
馬鹿と阿呆の絡み合い

514 :デフォルトの名無しさん:2012/08/09(木) 22:25:27.38
>>512
OSの知識なんて2chにレス出来るだけで十分。

515 :デフォルトの名無しさん:2012/08/10(金) 05:16:29.17
>>512
> そんなんでやって行けるんでしょうか

ん?
ネットワークプログラミングの仕事でもやらされようとしてるのか?
とりあえず、どのOSでやろうとしてるかぐらい書いたほうがいい。

516 :デフォルトの名無しさん:2012/08/10(金) 08:41:46.55
>>515
すいませんどのOSかはまだわかりません
来年からSEPGやることになったのですがなにがなんだかわからない状況です
金融系業務システム(社内ネットワーク?)と組み込みを中心にWeb開発もやってると言っていました

517 :デフォルトの名無しさん:2012/08/10(金) 08:57:15.31
金融系業務システムと組み込み Web 開発?

ていうか、SEPG ってうちだとネットワークの設計までしかやらないけど、
一般にはネットワークプログラミングまでやるもんなのか?

518 :デフォルトの名無しさん:2012/08/10(金) 08:58:34.29
来年からなら来年考えればいい

519 :デフォルトの名無しさん:2012/08/10(金) 10:29:26.19
テンプレ見て本買って勉強しようと思えない奴はどうしようもない。

520 :デフォルトの名無しさん:2012/08/10(金) 11:16:15.99
>>517
単なるWebアプリ開発だと思われますな。
おそらくネットワークプログラミングは何の関係も無い。
ドナドナ要員でしょうなぁ。ご愁傷様です。

521 :デフォルトの名無しさん:2012/08/10(金) 12:33:18.14
ネトウヨ記念(画像あり)
http://www.shogakukan.co.jp/magazines/detail/_sbook_2300508112
http://www.shogakukan.co.jp/var/files/storage/images/node_43/node_61/node_122/node_128/node_132/node_184/sapio12/6524796-2-jpn-JP/SAPIO.jpg

522 :デフォルトの名無しさん:2012/08/10(金) 18:57:53.71
>>517
たぶん、専門分野とか関係なくダボハゼのように仕事を取ってくる下請けなんだろ。

523 :デフォルトの名無しさん:2012/08/10(金) 20:43:19.97
売るか売られるか。それだけだもんな、人月商売はw

524 :デフォルトの名無しさん:2012/08/10(金) 20:57:23.32
MODBUS TCPてC#のTCPClientで送受信できますでしょうか?
ペーパレスチャートレコーダーに流れてくるデバイスバスの瞬時値を
横から分捕りたいなと。

525 :デフォルトの名無しさん:2012/08/10(金) 21:01:33.69
意味不明、エスパーカモーン

526 :デフォルトの名無しさん:2012/08/10(金) 21:30:38.10
>>524
モドバス側がTCP Serverで複数接続可能なら出来るかも

527 :デフォルトの名無しさん:2012/08/10(金) 21:44:14.09
クライアントがマスターでServerはSlaveだったっけ?

528 :デフォルトの名無しさん:2012/08/10(金) 23:00:37.84
>>527
それはMODBUSプロトコルの話かな?
TCPポートを開いて待機している方がサーバです。

529 :デフォルトの名無しさん:2012/08/10(金) 23:03:18.22
>>524
通信用のミドルウエアないの?

530 :デフォルトの名無しさん:2012/08/10(金) 23:58:56.78
フィールドバスか・・・ 今は何処のプロトコルが主流なんだろう?

531 :デフォルトの名無しさん:2012/08/11(土) 00:15:34.18
JKプロトコル

532 :デフォルトの名無しさん:2012/08/11(土) 00:59:30.86
>>530
世の中、HTTPばかりだろう

533 :デフォルトの名無しさん:2012/08/11(土) 10:59:35.94
次の関数 opにある 変数宣言の欠陥とセキュリティホールを指摘せよという問題がわかりません。セキュリティホールは rcv(sock, pkt->hd.sz, pkt->data); のバッファオーバーフローだと思うんですが
変数宣言のほうはint fd; の初期化がなされていないためfd代入前に case OP_READを貰うと想定外のread();をしてしまうということでしょうか?

void op(int sock, packet *pkt) {
 int fd; // declaration 1st
 int n = -1; // declaration 2nd
 switch (pkt->hd.cmd_or_stat) {
  case OP_OPEN:
   rcv(sock, pkt->hd.sz, pkt->data);
   pkt->data[pkt->hd.sz] = 0;
   fd = open(pkt->data, O_RDWR);
    if (fd > 0) pkt->hd.cmd_or_stat = SUCCESS;
     else pkt->hd.cmd_or_stat = FAIL;
   pkt->hd.sz = 0;
   break;

  case OP_READ:
   if (fd > 0) n = read(fd, pkt->data, 512);
   if (n < 0) {
    pkt->hd.cmd_or_stat = FAIL;
    pkt->hd.sz = 0;
   } else {
    pkt->hd.cmd_or_stat = SUCCESS;
    pkt->hd.sz = n;
    }
   break;
  case OP_CLOSE:
/* the following code is omitted. */
 }//end of swith()
}// endof op()

534 :デフォルトの名無しさん:2012/08/11(土) 12:35:30.24
ローカル変数は関数を抜けたら消えるから OP_OPEN で呼ばれたときに保存したつもりの fd は次に OP_READ で呼ばれたときには消えている
セキュリティホールは俺の予想では open するファイル名じゃね
仕様不明ゆえに確かなことは言えんけど、
例えば sock から /etc/passwd とか受信してもそのままオープンしちゃっていいんかね
まぁ実効ユーザを適切に隔離してればいいのかもしれんが

535 :デフォルトの名無しさん:2012/08/11(土) 13:05:08.72
rcv() って?

536 :デフォルトの名無しさん:2012/08/11(土) 13:11:54.76
snd, rcv は送信、受信メソッドです

537 :デフォルトの名無しさん:2012/08/11(土) 13:21:34.04
>>533
2つの問題以外にも突っ込みどころまんさいだな。

538 :デフォルトの名無しさん:2012/08/11(土) 13:30:29.77
>>537
これの8ページのか。
東大だよw
http://www.i.u-tokyo.ac.jp/edu/course/cs/pdf/2009computer.pdf

539 :デフォルトの名無しさん:2012/08/11(土) 13:35:43.49
op() の所だけ貼り付けられてもわからんな

540 :デフォルトの名無しさん:2012/08/11(土) 13:39:17.72
/* the external declarations are omitted. */
typedef struct header {
 int cmd_or_stat;
 int sz;
} header;

typedef struct packet {
 header hd;
 char data[512];
} packet;

void mainbody() {
 int sock;
 packet pkt;
 sock = getConnection();
 while (rcv(sock, sizeof(header), &pkt)) {
  op(sock, &pkt);
  snd(sock, sizeof(header) + pkt.hd.sz, &pkt);
 }
 closeConnection(sock);
}


541 :デフォルトの名無しさん:2012/08/11(土) 15:07:14.04
なんつーかダメプログラムの見本みたいなコードだな
バグを別にしても

542 :デフォルトの名無しさん:2012/08/11(土) 15:11:09.30
>>541
東大大学院入試問題なんだが・・

543 :デフォルトの名無しさん:2012/08/11(土) 15:17:33.10
東大()

544 :デフォルトの名無しさん:2012/08/11(土) 15:27:06.74
>>542
それがどうかしたのか?
誰が作ってもダメなものはダメだよ。

545 :デフォルトの名無しさん:2012/08/11(土) 15:32:45.75
ここまで具体的に駄目な点が指摘されていない、いや指摘できなくて単に駄目よばわりして鬱憤を晴らしている件について

546 :デフォルトの名無しさん:2012/08/11(土) 15:43:32.74
回答者を悩ませるためにあえて無意味にややこしい書き方をした可能性もある

547 :デフォルトの名無しさん:2012/08/11(土) 15:51:43.95
>>543
最近2chで○○()を良く見かけるけど『()』ってどういう意味?

548 :デフォルトの名無しさん:2012/08/11(土) 15:52:53.80
>>547
中身空っぽわろすって意味

549 :デフォルトの名無しさん:2012/08/11(土) 16:00:32.64
>>545
> ここまで具体的に駄目な点が指摘されていない、いや指摘できなくて単に駄目よばわりして鬱憤を晴らしている件について

>> char data[512];
>> if (fd > 0) n = read(fd, pkt->data, 512);

512 なんて書く奴今時いないんじゃね?

>> while (rcv(sock, sizeof(header), &pkt)) {
>> rcv(sock, pkt->hd.sz, pkt->data);

rcv( ) の戻り値を使っているところとそうでないところがある。

あと、op( ) 内の n の初期化と、実際に使っている case OP_READ: の間が離れすぎ、
初期設定は case OP_READ: 内でやったほうがいい。

550 :デフォルトの名無しさん:2012/08/11(土) 16:02:23.36
>>548
それ考えたのLisperの仕業かな

() ⇒ NIL 空っぽ

551 :デフォルトの名無しさん:2012/08/11(土) 16:04:27.50
>>549
rcv()には戻り値ないけど

552 :デフォルトの名無しさん:2012/08/11(土) 16:06:07.87
>>549
重箱の隅乙

553 :デフォルトの名無しさん:2012/08/11(土) 16:08:15.05
>>551
戻り値ないなら while( ) 内で使っちゃダメでしょ。

想像だが、読み込んだバイト数を返すようになってて、相手が切断したら 0 を
返すようになっているんだと思う。

つまり、ヘッダー読み込んだあとにいきなり切断される状況を考慮していない。
まあ、問題だから、それぐらいはいいかと思うが。

554 :デフォルトの名無しさん:2012/08/11(土) 16:09:26.31
>>552
どこがダメか指摘しろって言うから指摘したら、重箱の隅とか。
出来ない子の典型かよ。(w

555 :デフォルトの名無しさん:2012/08/11(土) 16:11:53.64
>>553
設問にrcv()の戻り値についての記述がないなw

556 :デフォルトの名無しさん:2012/08/11(土) 16:14:17.73
>>553
rcv()は常に成功するとある。

557 :デフォルトの名無しさん:2012/08/11(土) 16:23:36.51
>>555
うん、だから >>553 に書いた想像の域は超えない。

>>556
あるけど、それが何か?
Linux とかの recv( ) で、-1 が返ることはないよ、ぐらいの意味だと思う。

558 :デフォルトの名無しさん:2012/08/11(土) 16:40:46.81
おいおい、
>>545 が問題作成者だったらまんまと釣られてしまったね。

559 :デフォルトの名無しさん:2012/08/11(土) 16:50:07.31
別にこれで問題がより洗練されるなら、いいと思うぞ。

560 :デフォルトの名無しさん:2012/08/11(土) 16:51:00.97
学生の宿題(?)と分かって誰も真面目に答える気がないなwww

561 :デフォルトの名無しさん:2012/08/11(土) 17:12:31.82
>>533-534 以外にあると思うなら、書いてやれよ。

562 :デフォルトの名無しさん:2012/08/11(土) 17:33:41.57
大学の教官が書くコードだから、このレベルでも通用するんだろう。
昔、某メーカで研究所で開発されたプロトタイプを製品化するプロジェクトに関わったけど、
最初にやったのがコードの整理だった。奴等、確かに技術力はあるけど保守とか考えていないからね。
>>538にはソフトウェア科学専攻とあるし、こんなもんだと思う。

>>549の指摘が重箱の隅(>>552)とか不真面目(>>560)とか言ってるのも学生さんなんだろな。
それでもいいだろうし、社会人になってから勉強して体で覚えるしかない気がする。


563 :デフォルトの名無しさん:2012/08/11(土) 17:46:13.53
ダメプログラムの見本と言うほどじゃあないかと。

564 :デフォルトの名無しさん:2012/08/11(土) 17:49:37.56
オープンソースも似たようなもんだけど

565 :デフォルトの名無しさん:2012/08/11(土) 17:57:45.23
良くないものだったから問題に使ってさらし首にしてやったってこと?

566 :デフォルトの名無しさん:2012/08/11(土) 17:59:47.53
>>547
(笑)から笑を取り除いて失笑って説を見たことがある

567 :デフォルトの名無しさん:2012/08/11(土) 18:04:18.05
>>565
その可能性もあるなw

568 :デフォルトの名無しさん:2012/08/11(土) 19:03:51.30
>>540がダメプログラムな最大の理由、それはエラー処理を考えていないこと
関数op()はvoid型でopen()/read()システムコールがエラーになった場合、
引数の構造体メンバ pkt.hd,cmd_or_status へFAILを設定するけど、
その値をメインループ内で参照していない。これはop()が戻った直後に検査してループを脱出すべき。
また>>538によればファイルサーバとあるから、errnoを参照して適切なメッセージをsyslog等へ保存すべき。

結論としては、学校のお勉強や試験問題であれば許されるけど、仕事で書かれたコードだとしたら
>>549の指摘を含めてダメダメプログラムだと断言する。
たぶんコードレビューだと、最初の5分で中断して再レビュー要と判定されるレベル。
レビュアーは「こいつもやっぱり学はあっても使えない(=即戦力にならない)」と心の中でつぶやくだろう。

569 :デフォルトの名無しさん:2012/08/11(土) 19:28:12.73
問題用のプログラムでエラー処理とか、馬鹿じゃね?

> 引数の構造体メンバ pkt.hd,cmd_or_status へFAILを設定するけど、
> その値をメインループ内で参照していない。これはop()が戻った直後に検査してループを脱出すべき。

クライアントに返してるだろ、勝手に仕様作るなよ。

5分で、「頓珍漢な発言するなよ、うぜー」と他のレビューアから思われるタイプだな。

570 :デフォルトの名無しさん:2012/08/11(土) 19:33:07.33
もっと重大な誰が見てもわかるセキュリティホールがあるのにね

571 :デフォルトの名無しさん:2012/08/11(土) 19:35:03.09
へー、そーなーんーだー (棒)

572 :デフォルトの名無しさん:2012/08/11(土) 20:50:37.42
getConnection 関数は、クライアントからのTCPコネクションを確立し、そのコネクションに関連づけられたファイルディスクリプタを返す。
closeConnection関数は、引数で与えられたファイルディスクリプタに関連付けられているコネクションを閉じる。
snd およびrcv 関数は、送信、受信関数であり、
第一引数にコネクションに関連づけられたファイルディスクリプタ、第二引数に送信あるいは受信バイト数、第三引数にデータのアドレスを与える。
これら4つの関数実行(getConnection, closeConnection)は常に成功すると仮定する。

open(ファイル名) return ファイルディスクリプタ、 失敗時 -1 を返す。
read(ファイルディスクリプタ、格納先メモリアドレス、データサイズ) return 読み込んだサイズ。失敗時 −1を返す。


573 :デフォルトの名無しさん:2012/08/11(土) 21:23:36.61
>>569
>問題用のプログラムでエラー処理とか、馬鹿じゃね?

>>568では「試験問題であれば許される」と書いてあるけどな。

>クライアントに返してるだろ、勝手に仕様作るなよ。

クライアントへのエラー応答とは別に、サーバプログラムとしての適切なエラー処理を検討すべき。

>5分で、「頓珍漢な発言するなよ、うぜー」と他のレビューアから思われるタイプだな。

このくらいの指摘でウゼーと感じるようだと成長できないよ。
まあコード品質に関する基準がその程度の組織なら、厳しいと感じるかもしれないけどね。

574 :デフォルトの名無しさん:2012/08/11(土) 21:27:26.05
東大入試問題よりネスペの問題のほうがむずいよ

575 :デフォルトの名無しさん:2012/08/11(土) 22:02:57.98
>>573
しかし、>>540の適切なエラー処理ってどういうのを想定してるんだ?
仮にエラーを検知してwhileループを抜けてエラー処理したとして、
それが仕様で期待される動作なのか?

576 :デフォルトの名無しさん:2012/08/11(土) 22:12:13.96
あと、これも試験問題であればどうでもいい話だけど、パケット形式仕様に相互接続性のバグを抱えているね。
ローカルなプロセス間通信であればC言語の構造体を直にパイプやソケットへ流すのは普通。
でも、ネットワークであればCPUアーキテクチャ(エンディアン)やコンパイラ仕様に依存してしまう。
ちなみにUNIX標準のNFS(ファイル共用)では、XDRとよばれる環境非依存な形式が使われている。

577 :デフォルトの名無しさん:2012/08/11(土) 22:14:45.98
そんなもん実務では無視するだろボンクラ
俺知ってるアピールするとかパーかおめ

578 :デフォルトの名無しさん:2012/08/11(土) 22:22:50.26
>>576
>ローカルなプロセス間通信
とローカルでない通信を同じに議論してるの、あほちゃう

579 :デフォルトの名無しさん:2012/08/11(土) 22:32:03.14
>>575
すでに>>553-557で指摘されているけど関数rcv()の仕様が曖昧だから、何とも言えないw
もし成功の意味がC言語の真(0以外)であれば、プログラムは常に無限ループするから問題外。
もし>>553が想像したようにクライアントがcloseしたら0を返す仕様だとしても、
今のままだとエラー応答パケットを送信してコネクション切断が検出されるまでの時間、
サーバプロセスはコネクションに縛り付けられたままになる。
この振る舞いが正しいか否かはプロトコル仕様が提示されていないから、これまた何とも言えないw
ただし、一般的には回復不可能なエラーであればエラー応答パケット送信に続けてソケットをクローズし、
次のサービス要求の受付けを待つのがサーバとしての正しい動作だと(個人的には)思う。


580 :デフォルトの名無しさん:2012/08/11(土) 22:41:42.69
op()のエラー処理じゃなくてrcv()の話だったん?

581 :デフォルトの名無しさん:2012/08/11(土) 22:56:02.38
>>577
>そんなもん実務では無視するだろボンクラ

え、実験とか趣味なら無視というのなら分かるけど、実務で無視しちゃうの?
もしかして私は異世界の住人だったのかしら....w

あと、XDRは古い規格で(ほぼ)UNIX限定だからNFS以外ではほとんど使われていないけど、
今の時代ならProtocol BufferやMessagePackみたいに(比較的)手軽な実装が存在するから、
怖がらずに一度挑戦してみることを薦めるよ。

>>578
そのローカルなプロセス間通信とローカルでない通信とを同じ感覚で考えていたのが
出題コードを書いたプログラマで、>>576では「その考え方は間違っていますよ」と指摘している。
日本語読めますか?

582 :デフォルトの名無しさん:2012/08/11(土) 23:05:00.50
>>581
しらんがなー

583 :デフォルトの名無しさん:2012/08/11(土) 23:08:43.38
時代はASN.1

584 :デフォルトの名無しさん:2012/08/11(土) 23:20:22.71
>>581
実務なら逆に、「サーバーとクライアントの環境合わせるからオッケー」てなもんだろ。

585 :デフォルトの名無しさん:2012/08/11(土) 23:42:21.91
>>584
それが通用するような案件しか関われず、しかも問題意識を持たず実務をこなしていたとしても、
それはそれで本人のエンジニア人生なんだから、まあいいんじゃね........

586 :デフォルトの名無しさん:2012/08/11(土) 23:56:33.77
要は実務じゃ原理主義的なべき論じゃなくて目的を達成できればいいってことだろ?
異種環境での移植性が要件にあればそうするだろうさ。

587 :デフォルトの名無しさん:2012/08/12(日) 01:09:47.05
もともと面白くないお題だったが、ここまで落ちるともう停めるべき。

588 :デフォルトの名無しさん:2012/08/12(日) 01:15:05.87
未だにセキュリティホールの具体的な指摘は全く無いが。

589 :デフォルトの名無しさん:2012/08/12(日) 01:46:59.87
入力をpacketにつめてpacket.dataをチェックせずそのままopenに渡してるから
サーバが想定していないファイルにアクセスされる可能性がある
chrootしてあるとかサーバの権限上問題ないといった断りがなければ
セキュリティホールといって問題なさそうなものだけど

590 :デフォルトの名無しさん:2012/08/12(日) 09:09:20.66
>>534

591 :デフォルトの名無しさん:2012/08/12(日) 10:47:52.67
>>573
× このくらいの指摘
○ 頓珍漢な発言

592 :デフォルトの名無しさん:2012/08/14(火) 09:05:38.01
東大ってこんなレベルが低いプログラム組むの?

593 :デフォルトの名無しさん:2012/08/14(火) 10:33:50.09
>>565

594 :デフォルトの名無しさん:2012/08/14(火) 11:56:56.68
恥ずかしい奴大杉

595 :デフォルトの名無しさん:2012/08/17(金) 06:31:50.98
            / ̄ ̄ ̄ `\
           /:\___从__ヽ
           i::/ ''''''  ''''''' i
           |:/ /゚ヽ  、/゚ヽ|  このスレ、癒されるなあ。。^^
           (6    ,ノ(、_,)、   |
           ヽ    ト==イ  ノ
             \_'Uニ´_,/
             /   /
           /   /
         /    /
        :/       ヽ:
       :/         ヽ:  皆さん、グッジョブです!
       :( *‘ω‘*)*‘ω‘*):
     ./          \,
     /   ,     .    、 'i
    ./   r´    人.    ヽi
    i   人_,、__ノ  ヽ、_,,_ノ.|
    |   /  ゚        ゚ .|.|
    |  /(       .з   .iノ

596 :デフォルトの名無しさん:2012/08/22(水) 06:32:22.54
説明用に簡略化したコードが鬼の首になるとは…

597 :デフォルトの名無しさん:2012/08/24(金) 20:48:24.55
http://jp.reuters.com/article/topNews/idJPTYE87N03W20120824
東証で7日に生じたシステム障害では、TOPIX先物やJGB先物など
東証が提供しているデリバティブ商品のすべての取引が停止した。
東証のシステムは、稼働中の機器が故障した場合に予備機に切り替わる仕組みに
なっている。2月の障害ではこの切り替えがうまくいかなかった反省から
システム総点検を実施し、稼働中の機器の電源を切って予備機への切り替えを
確認していた。しかし8月の障害では、稼働中の機器の一部で不具合が
生じただけで機器自体の稼働が停止しないうちに予備機が稼働したため、
機器間の通信が混乱する事態になったという。

598 :デフォルトの名無しさん:2012/08/26(日) 03:17:41.50
家電屋で売ってる市販ルータとL3スイッチってどう違うんですか?

599 :デフォルトの名無しさん:2012/08/26(日) 04:47:45.85
>>598
家電屋で売っているルーターと名乗る物は、殆どの場合ルーターではなくNAPTサーバで
ルーターとしての機能は極めて限定的。

ルーターとL3スイッチは機能的には同じものだが、ハードウェアで処理するものがL3スイッチ、
ソフトウェアで処理するものがルーターと名乗っている事が多い。

600 :デフォルトの名無しさん:2012/08/26(日) 07:11:30.32
機能は限定されているがrouterには違いない。というか、NAPTは
L3で動作する以上、必然的にroutingの機能が必要。

・家庭用routerのほとんどはWAN側とLAN側の2ポートしか持たない。
 (一部、DMZ用ポートを持つ製品もある)
・それぞれのポートはあらかじめ用途が決まっていて、対称ではない。
・ほとんどすべての製品でNAPTを搭載する。多段NATを検知して
 自動的にNAPT/routingを停止する製品も存在するが、明示的に
 NAPTを停止できる製品は少ない。

601 :デフォルトの名無しさん:2012/09/03(月) 01:01:16.73
ソケットプログラミングについて質問があります。
UDPでjpegの画像ファイルを転送したいのですが
どうすればいいのでしょうか?
ちなみに言語はCです。
よろしくお願いします!

602 :デフォルトの名無しさん:2012/09/03(月) 01:03:00.73
速度目的でUDPを使うな。

603 :デフォルトの名無しさん:2012/09/03(月) 01:05:04.96
こっちで質問するなら、C言語の方にちゃんと書いとけよ。

あと、速度重視で UDP とか言うなら、こっちにも書いとけよ。

604 :デフォルトの名無しさん:2012/09/03(月) 01:13:04.59
UDPは垂れ流しの無手順だから、早いってだけなの
送信データが相手に届くかどうかの保証がない分

605 :デフォルトの名無しさん:2012/09/03(月) 01:17:22.50
色々とすみません。
速さが一番重要なのでそこは
かまいません。
jpegをバイナリデータとして転送する
方法が知りたいんです。

606 :デフォルトの名無しさん:2012/09/03(月) 01:20:13.73
速度目的でUDPを使うな。

607 :デフォルトの名無しさん:2012/09/03(月) 01:21:04.11
その程度の事なら、netで探せばサンプルみたいなのはいっぱい見つかるでしょ
自力でやってみないと、UDPがどういうものなのかはわからんかもね

608 :デフォルトの名無しさん:2012/09/03(月) 01:22:15.44
> UDPでjpegの画像ファイルを転送したいのですが

tftp でも使っとけよ。

お前にはプログラミングは無理そうだし。

609 :デフォルトの名無しさん:2012/09/03(月) 01:24:18.83
>>605
> 速さが一番重要なのでそこは

じゃあなおさらTCP使え。
まだまだUDPで早い転送プログラム書くのは無理。
10年くらい修行してから出なおせ。

610 :デフォルトの名無しさん:2012/09/03(月) 01:24:33.05
受信でもなく送信でもなく転送ってところがミソなんですよきっと

611 :デフォルトの名無しさん:2012/09/03(月) 01:24:36.35
ttp://srgia.com/docs/rfc768j.html
これでも、ながめてみたら、速度重視君は

612 :デフォルトの名無しさん:2012/09/03(月) 01:26:12.73
そうですね。
自分でもうすこしやってみます!

TCP,UDPの違いは分かっているつもり
です。
最終的には、画像を連続的に転送して
画像処理を行う事を目標にしているので
リアルタイム性を重視してUDPをチョイス
しているだけです。

613 :デフォルトの名無しさん:2012/09/03(月) 01:26:39.17
connectしてsendするだけだろ

614 :デフォルトの名無しさん:2012/09/03(月) 01:30:59.50
ローカルでやるなら、UDPでもいいかもね

> TCP,UDPの違いは分かっているつもりです。
やってるうちに、ハマりましたって、オチになりそうな

615 :デフォルトの名無しさん:2012/09/03(月) 01:32:07.77
わかってないからみんなに突っ込まれてるのにな。

616 :デフォルトの名無しさん:2012/09/03(月) 01:38:12.93
知識不足で申し訳ないです。

TCPとUDPの選択としては、
目標の早さを実現できるなら
どちらでもいいんです。
ただリアルタイム性という点では、
UDPに分があると思っただけです。

一度、両方試して比較してみたいと
思います。
色々とアドバイスありがとうございました。

617 :デフォルトの名無しさん:2012/09/03(月) 01:39:37.37
人の話を聞く気が無いなら初めから質問するな

618 :デフォルトの名無しさん:2012/09/03(月) 01:39:38.82
>>614
ローカルで行うことを想定しています。
ありがとうございます。

619 :デフォルトの名無しさん:2012/09/03(月) 01:43:17.99
音声データなら、データ抜けしても、それなりに、復帰できるんだけど
jpegだとフォーマットにその手の仕掛けがあるんかね

想像するにFAXみたいなことをやろうとしてるのかな?

620 :デフォルトの名無しさん:2012/09/03(月) 01:48:00.71
>>619
いえ、どちらかといえばストリーミング動画配信
のようなものを実現したいと考えています。
画像処理する上で画像の方が扱いやすいので…



621 :デフォルトの名無しさん:2012/09/03(月) 01:49:29.80
パケットが届かないかもしれないだけじゃなくて
データが届く順番も保証されてないから
jpeg受信して表示したいとしたら面倒

622 :デフォルトの名無しさん:2012/09/03(月) 01:53:56.44
好きにやらせてやれよ。

623 :デフォルトの名無しさん:2012/09/03(月) 01:55:33.98
そうですね。
色々考えてるとUDPだと
厳しいかもしれませんね。
やはり皆さんが言ってる通り
TCPでやった方が良さ気ですね。

個人的にはUDPは、TCPと実際にどう違うのか
比較してみたくなりました。
色々とありがとうございます!

624 :デフォルトの名無しさん:2012/09/03(月) 02:07:45.88
>>620
ローカルで実験的にやる分には、UDPで出来ることだよ、それは
WANでやると、ボロボロになる可能性大のような

jpegじゃなくでストリーミング向けの画像フォーマット
探すなり、考えるなりしたほうがよくね

625 :デフォルトの名無しさん:2012/09/03(月) 13:54:19.97
直結 gigEカメラの映像転送でさえ、かなり苦労してるっぽいのに…

626 :デフォルトの名無しさん:2012/09/03(月) 15:16:25.10
>>624
WANどころか、UDPでやると転送が2つ開始しただけで、かなりややこしいことになる。

627 :デフォルトの名無しさん:2012/09/03(月) 15:23:18.62
は?

628 :デフォルトの名無しさん:2012/09/03(月) 16:25:07.57
うん、ややこしくなるな

629 :デフォルトの名無しさん:2012/09/03(月) 16:44:17.55
音声と画像を同じパケットにしてみるとか
UDPで1パケ512バイト以上に出来るなら

630 :デフォルトの名無しさん:2012/09/03(月) 16:52:27.90
受信側でパケットが来なかった時の補正が出来るようにしとけば
UDP2個使いも出来るかも

631 :デフォルトの名無しさん:2012/09/03(月) 16:55:07.41
パケロスやパケ順入れ替え〜再生側時刻との乖離が激しくて実質ロス扱いの時の対処が問題

過去からの予測で済ますのか、再送するのか、ロスでほっとくのか

632 :デフォルトの名無しさん:2012/09/03(月) 17:09:29.32
再送してたらTCPとほとんど一緒だからな
ロスは放って置いて補間なり無視なり

633 :デフォルトの名無しさん:2012/09/03(月) 17:16:51.47
そういえばWinnyの人の会社がUDP上に速いTCP的プロトコルを作ったってのをどこかで読んだ

634 :デフォルトの名無しさん:2012/09/03(月) 19:53:13.91
遠回りに見えるかもしれないけど、RTPがどんなことをやってるかとか
調べてみるのがいいんじゃないの?

635 :デフォルトの名無しさん:2012/09/03(月) 20:19:16.57
へー、遅延時間の計算の仕方まで書いてあるんだ、解説ページ

636 :デフォルトの名無しさん:2012/09/03(月) 21:09:46.48
          /        ,       ::| |ヽ\    \
          /      /  / |     ::/| :| `、`、    ヽ
           /      /  / |    ::/ |::|  `、',ヽ  ',  ',         r┐ r┐ヾ>
         ,'   i   | :/'  | |  ::/ i:|    ', i ヽ  i  ',.       | | lニ コ
        ,'   |     ! :,'   i||  ::/  ||     || `、 | | |        | レ! _| |.
         |   |    |`i'-,,, | | ::/   |     |  ', | | |        ヽ/(___メ>
          |   |    ||.|  `二=,,__,,,     ,,,__... -!´ト, | |         ,、
      .  | .   i    | |  //:::C,       7::c\ ||ヘ.| |        ((
          |   .|     | /  {::::::::::::}         {::::::::}`、 ,' .| i         ))
        | /´'|     |     ヽ::::::ノ       ヾ::ノ  .|   |        ((
        | {  |    |::::::::         ,    .... |   |         ))
        |  \',   '','''''   __       ::::::::: |   i           ((
        |   .:::',   ',   /    ` ー --、    |   |            ))
        /  .:::::::', ::  ',  /          }    /   |         ((
       / ...:::::::::::'、::.   ',、(          /  ,イ|:: :   |          `
     /  ..:::::::::::/'`、:::.. ',`'' - ,,____ノ,,ィ::´:::i ',:::|:: |         / 7
`-ー-´/ /:::::::::/    `、、 ',   /`、\:::::::::::::::,':::::::,' |::||:: |       ┌‐' 'ー┐ト、
 ̄ ̄/  ./:::::,-{       \ `、、   /  \::::::::,'::::::/  .|:i'|: |        7 /_7 / 」__〉
  /   //  \       \ ヽ/    }::::/:::::/   | |:|        〈_/ヽ_/


637 :デフォルトの名無しさん:2012/09/03(月) 21:31:48.54
rm r,      タマの裏までしっかりね〜!     .なわ┌─┐
.ヾ_`ヽ   キ                  キ    /),;彡んた | .ち│
  \\   ャ . ,、    ,.-─‐-、    ャ     l ,- / でし│ん .!
  赤\\  ッ !`ー--/ /´`´`ヽ    ッ    // 聞もた | .ち│
  ち.  \`ー、__.`ー-i / ∩ ∩ |    ,.-‐´/  い ち...| .ん |
.   ゃ    `-、_ 7´`ヽ|  r─-, .|_,.-,.-´ ,.-‐´ア  て に.└─┘
  ん       オ Y_   ト、_ヽノ /  |_,-´  ハ   ね
勃 も .__  ホ ヽ / |_二| |_,.-´   __ハ    !
起  /;;;;;;;;;;;;;;ヽ ホ  |ノ      |  ,.-‐´:::::::::ヽ_ 大な怖 あ洗皮
す /;;;;;;-‐´`ヾ;_,.-‐´      / /::r‐-::::::イ:::::::i 丈.く.が げっ を
る . {;;! ^ L!^ |  (⌒)    (ll (::::|の へ/::::::::::}夫て.ら て.て.む
の ヾ、_ ノ▽ /-、-イ |     ._||_っ`| く_  )::::::::::::}!も  !  .い
よ  ./ ヽT二T|/ イ |    (ミ / .\┘人,--、/          て
∫  |  |  / /ー-´     ヽ /    ̄| /   ヽ
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
    _  i⌒i    い 拭    __   ま う      ┌─┐
   .ト;;;;;i.く :.|     い け  /´   \.  ぁ ん       .| .ま..|
    XT  !.ノ    か ば  .|⌒⌒ヽ  |__ :  ヽ__ .   | .ん |
   i7N_       ら     |,-、,-、| 人ヽ   /::::::::::::l   .| .こ .!
   7_N             ヽー  |./  ヽ!  (:::::::::::::/|  └─┘
 ̄ ̄|/ヽ| ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄7--イ/\ ̄ ̄ ̄/ー,-|ノ ̄ ̄ ̄ ̄ ̄
   ̄  ̄             /ー┘!  .〉   / /| ヽ,,/`丶、
                  (    | Y |   .|/ .|,-くヽ-‐、/
                   |    | | .|  /f   | r‐Y二/───
                   |    ヽ./  | .|   | ト、_____
                   |     |   .| .|___l .!  |


638 :デフォルトの名無しさん:2012/09/03(月) 22:57:21.05
>>631
再発明しなくても、RFC-3350にRTP(A Transport Protocol
for Real-Time Applications)ってのがあるから、
真似したらいい。

639 :デフォルトの名無しさん:2012/09/04(火) 00:40:53.81
MDPは

640 :デフォルトの名無しさん:2012/09/04(火) 09:36:35.24
たまにUDP使うくせにデータの遅延や欠落を考慮して再送やチェック入れまくった結果TCPの劣化版作ってる知能障害がいるけどあれは何ですか?

641 :デフォルトの名無しさん:2012/09/04(火) 09:49:46.93
またUDPか
ホント後を絶たないねこの手の勘違い

642 :デフォルトの名無しさん:2012/09/04(火) 10:17:48.13
UDPってどんくらい早いの?

643 :デフォルトの名無しさん:2012/09/04(火) 10:28:09.84
はやいわけではない

644 :デフォルトの名無しさん:2012/09/04(火) 10:32:11.48
>>640
SCTPを教えてやれ

645 :デフォルトの名無しさん:2012/09/04(火) 15:45:05.95
>>638
流し読みしたけど、NTPと同じような方法で遅延計算できるしくみが内包してるのね
なかなか興味深い

646 :デフォルトの名無しさん:2012/09/04(火) 23:40:53.25
FA用途の汎用ネットワークプロトコルって今は何が一番高速なんすかね?CC-LINK IE?

647 :デフォルトの名無しさん:2012/09/04(火) 23:52:59.90
距離とか数とか接続元/先とか考慮しなきゃならんのじゃないかね

648 :デフォルトの名無しさん:2012/09/05(水) 00:27:47.93
高速ってのもなんだかな

649 :デフォルトの名無しさん:2012/09/05(水) 04:45:58.17
>>646
>FA用途の汎用ネットワークプロトコル
なにそれ、すれちそう

650 :デフォルトの名無しさん:2012/09/05(水) 22:46:43.02
て言うか、○○用途 の 汎用 って矛盾してないか?

651 :デフォルトの名無しさん:2012/09/05(水) 23:00:15.95
無手順だから早いってだけで
やり取り入れりゃ、ものによっては遅くなったりするわな、UDP
TCP使っても、相手がだんまり決め込む可能性があるってのが味噌

652 :デフォルトの名無しさん:2012/09/06(木) 03:10:22.01
TCP使ってるのに、相手が無応答の時は再送処理をしろ
という仕様を突きつけられた。

653 :デフォルトの名無しさん:2012/09/06(木) 07:30:53.20
要件によっちゃあ、それが必要な場合もあるだろ?

654 :デフォルトの名無しさん:2012/09/06(木) 08:21:58.88
APとプロトコルレベルは違う

とまじれす

655 :デフォルトの名無しさん:2012/09/06(木) 09:16:18.41
>>652
やれば、良いんじゃね?

TCPにおける再送処理は接続からやり直せば意味あるし、
実際におれも一定時間内に応答が無ければ接続からやり直すって
処理は良く作ってたよ。

656 :デフォルトの名無しさん:2012/09/06(木) 17:57:25.67
>>655
接続しなおせば当然意味あると思うけど
そのままやれって意味わかんないよね

657 :デフォルトの名無しさん:2012/09/06(木) 18:39:46.33
>>656
まぁ、普通は意味が無いけど、場合によっては意味がある。

たとえばプロトコルに通信シーケンスがずれた場合の復旧処置が
含まれている場合。相手側は次のトークンを待っている可能性がある。

後はバッドノウハウだけど、単純に相手側とか、プロトコルスタックの
バグで、後続のデータを受信すると正常に動き始めるとかwww


658 :デフォルトの名無しさん:2012/09/07(金) 01:38:36.44
イー・アクセスが通信障害の原因を発表、人的操作ミスとソフト不具合が重なる 2012/09/06
http://itpro.nikkeibp.co.jp/article/NEWS/20120906/421101/?top_tl2

 イー・アクセスは2012年9月6日、5日午後6時51分から午後11時34分にかけて、
12都府県で携帯電話の音声通話とデータ通信が利用しづらい状況に陥った障害の
原因を公表した。保守作業時の人的操作ミスとソフトウエアの不具合が重なった。
影響数は最大約27万人としている。
 同社は「ネットワークオペレーションセンター」(関連記事)で携帯電話網を
遠隔監視しているが、5日の保守作業時に基地局の状態を調べるコマンドの
パラメータを間違えて設定してしまったという。パラメータを誤ったコマンドは
システム側ではじく仕組みとしていたが、ソフトウエアの不具合で有効に機能せず、
そのまま実行されて「基地局が異常な状態に陥ってしまった」(同社)。
同社は影響を受けた基地局の数を非公表としているが、12都府県のある程度
まとまった単位の基地局に対して同コマンドを実行してしまったとみられる。
 最終的に問題の基地局を遠隔から再起動させることで対処したが、原因の究明に
手間取り、復旧までに約5時間弱を要する結果となった。
 イー・アクセスは今後の再発防止策として、
(1)保守作業方法の事前チェック体制の強化、
(2)作業プロセス上のチェック工程の改善、
(3)ソフトウエアの不具合の改修の3点を挙げた。
(1)と(2)について既に対処済みで、(3)についても速やかに実施するという。

659 :デフォルトの名無しさん:2012/09/10(月) 21:55:58.01
>>657
シーケンスずれてしまって毎回 slow timer 一回待つってやつか?


660 :デフォルトの名無しさん:2012/09/11(火) 00:49:37.59
モルピグ作りたいんすけど普通はUDPとかゆうの使うんすか?????

661 :デフォルトの名無しさん:2012/09/11(火) 10:18:39.96
WinSock2でパケットキャプチャをしてたんですけど
どうも大量データを受信したときに取りこぼしが出てしまい
WinPcapを使ってみようと下記を参考にしてみたんですが
やはり取りこぼしが出てしまいます。
取りこぼしが出るのは仕方のないことなんでしょうか?
http://homepage3.nifty.com/teatea/parasite/CSmemo.htm#packet

662 :デフォルトの名無しさん:2012/09/11(火) 17:09:24.93
>処理の間に溜ったメッセージをパージする
これやってんじゃねえの?

663 :デフォルトの名無しさん:2012/09/11(火) 23:06:50.73
>>661
そう

664 :デフォルトの名無しさん:2012/09/12(水) 00:17:58.99
キャプチャ用のバッファーがあってそれが溢れちゃうみたいですね。
それなら仕方ないか・・・

665 :デフォルトの名無しさん:2012/09/12(水) 00:21:44.18
全部表示すんじゃなくて、IPとかの必要なもんだけ表示するとかやってみたら
基本的に狙い撃ちみたいなことしないと

666 :デフォルトの名無しさん:2012/09/12(水) 04:00:12.19
表示デバイスってのは人が思う以上にとんでもなく遅いから
ログを記録してから検索するとかしないと簡単にあふれる。

667 :デフォルトの名無しさん:2012/09/12(水) 07:21:03.24
自分のは表示はしてないんですけどね。
まあ取りこぼしは仕方ないみたいですね。

668 :デフォルトの名無しさん:2012/09/12(水) 20:39:43.89
きちんとやるなら、ハードウェアでやるしかないんだろうな。
http://www.lineeye.co.jp/html/product_LE-580FX.html

これでも、半二重 90Mbps、全二重 120Mbps 程度が限界らしい。

669 :デフォルトの名無しさん:2012/09/21(金) 20:42:42.27
linux上で、XDRというデータ形式を使用して通信しています。

クライアント側(linux 32bit又は64bit)でデータをENCODEし、サーバ側(linux 64bit)でDECODEしています。
ENCODEする際に、OSによりxdr_u_long又はxdr_int64_tを使用しているのですが、サーバ側でどのデータ型で
ENCODEした際のデータ型を知ることはできますでしょうか?

また、DECODEする際にxdr_u_long等の関数を呼び出すと内部のポインタが進んでしまうのですが、戻すことは可能でしょうか。

クライアント側のプログラムの入れ替えができない為、32bit,64bit共にxdr_int64_tを使用する方式に変更できない状況です。


670 :デフォルトの名無しさん:2012/09/21(金) 20:47:17.57
>>669
ttp://docs.oracle.com/cd/E19253-01/816-3978/6ma7kltok/index.html
net経由でやり取りしてるからと、ここで質問してる時点で...

671 :sage:2012/09/21(金) 21:19:46.86
>>670
ありがとうございます。

教えて頂いたページは確認済みです。
以下のリンクの情報でx_privateにデータが格納されている事まで確認しました。
x_privateのサイズから型を予想しようとmalloc_usable_sizeでサイズをとったのですが、
longの時とint64でサイズ同じで判断できなかったため、知っている方がおりましたら、
アドバイスを頂きたいと思っています。

ttp://docs.oracle.com/cd/E19253-01/816-3978/6ma7kltoc/index.html



672 :デフォルトの名無しさん:2012/09/21(金) 22:07:48.68
小さい方に合わせるんじゃないの

linuxの場合
longは
32bitOSで4バイト
64bitOSで8バイト

メモリ確保する時のポインタサイズは
32bitOSで4バイト
64bitOSで8バイト

言葉知ってるだけじゃ、そのうち潰れるよ

XDR ストリームインタフェースはバカなりの解釈だと
32bitアプリと64biアプリの型の隠蔽するのに関数ポインタを使って
場合分けしましょうってことで
受け渡しに使うもんじゃないって読めるな

質問の内容が高度すぎて、バカには何を質問してるのか、わからん

673 :デフォルトの名無しさん:2012/09/21(金) 22:23:12.10
あーC言語とかのlongかー

674 :デフォルトの名無しさん:2012/09/21(金) 22:41:46.56
>>672

ありがとうございます。

質問内容がわかりづらく申し訳ないです。

既存のシステムでXDRを使用してデータの受け渡しをしています。
サーバ、クライアント共に32ビットOSです。
ハードウェアの老朽化対応でサーバと一部クライアントのOSを64ビットにすることになりました。

上記のような状態で、交換前のクライアントは32ビットのため、クライアントは32ビットと64ビットが混在しています。
受け渡しデータが環境依存のデータで、32ビット時は4バイト、64ビット時は8バイトのデータをサーバに渡す必要があり、
サーバ側でDECODEする際にENCODEした時のデータ型を判断したいという内容です。


675 :デフォルトの名無しさん:2012/09/21(金) 22:47:21.85
>>674
ただのデータ変換にnetがどうのとか意味不明なの
最初にデータ構造考えた人に質問したほうがいいよ

676 :デフォルトの名無しさん:2012/09/21(金) 22:51:07.75
ストリームに何が入っているか判断するのは自己責任です。
タグでもなければ判断しようがない。

677 :デフォルトの名無しさん:2012/09/21(金) 23:17:19.32
なんか聞き覚えるなと思ってググッたら
メガドラで出てたんだな

678 :デフォルトの名無しさん:2012/09/21(金) 23:44:04.07
>>674
おそらく根本的な考え違いをしている(>>672も同じく)
すでに他の人(>>675,676)が指摘しているけど、
エンコードされたXDRデータには、そのデータ型を表現する情報は一切含まれていない

たとえばXMLであれば(XML Schema や Relax NG といった)スキーマ定義が無くても
タグがあるから受信側でXMLデータを(ある程度までは)解釈できる
JSONにしても、(リストやハッシュといった)構文からデータ構造を推測できる

しかし(繰り返しになるが)XDRにはこういった柔軟性は存在しない(=XMLやJSONの常識は通用しない)
>>674がやろうとしているのは、あるC言語の構造体のバイナリダンプを渡されて、
その構造体が定義されたヘッダファイル無しにダンプ解析を試みるに等しい

素直に、その既存システムが開発された時に作成されたXDR定義ファイル(*.xdr)を入手しなさい
もしもそのファイルが入手できないことを承知で案件を引き受けてしまったのなら、
その判断を下した馬鹿者の責任だから、傷が大きくならないうちにお客様にゴメンナサイを言うべき

679 :デフォルトの名無しさん:2012/09/21(金) 23:49:36.10
streamじゃなければ、staticに型は決まってますよ。

680 :デフォルトの名無しさん:2012/09/22(土) 11:42:13.47
>>679
その「型紙」を寄越せ、っつってんだろ

681 :デフォルトの名無しさん:2012/09/22(土) 12:47:03.31
て言うか何らかの手段で型紙を識別できる仕組み作らないと無理だろ。

そもそも「クライアント側のプログラムの入れ替えができない」とか書いてる割には、
「64ビット時は8バイトのデータをサーバに渡す必要があり」と書いてる。

まあ、マジだったとしても本人よく理解してないだろうし、スルーでいいと思うよ。

682 :デフォルトの名無しさん:2012/09/22(土) 15:50:02.41
>>680
streamなんですよ。

683 :デフォルトの名無しさん:2012/09/22(土) 18:38:53.36
I stream

684 :デフォルトの名無しさん:2012/09/22(土) 18:39:27.70
You stream

685 :デフォルトの名無しさん:2012/09/22(土) 19:02:21.79
好きさ!

686 :デフォルトの名無しさん:2012/09/22(土) 19:16:48.10
じじいがいる

687 :デフォルトの名無しさん:2012/09/22(土) 19:21:26.05
ばばあの可能性は?

688 :デフォルトの名無しさん:2012/09/22(土) 19:22:59.31
夏のおじいさん

689 :デフォルトの名無しさん:2012/09/22(土) 19:30:54.25
ジジイ、ジジイか
それじゃあお前は何だ、このガキが
俺はお前さんがこの世に落っこってくる前からコード書いてんだ

690 :デフォルトの名無しさん:2012/09/22(土) 19:32:14.20
とすると70〜80歳か。 すげぇな・・・

691 :デフォルトの名無しさん:2012/09/22(土) 21:37:21.89
ひんと:>>689 には元ネタあり

692 :デフォルトの名無しさん:2012/09/23(日) 02:58:10.78
>>690
とすると55〜65歳か。 すげぇな・・・

693 :デフォルトの名無しさん:2012/09/23(日) 03:00:39.25
あーそんな昔じゃコード書くのもっと年くってからか。

694 :デフォルトの名無しさん:2012/09/23(日) 08:06:49.13
送り手が送ってこない情報を受け手側で判断したいという
無理難題だから誰にも解決はできない。

695 :デフォルトの名無しさん:2012/09/23(日) 09:10:35.55
この板にはエスパーが居るんだから、そのエスパーをプログラミングすればいいんだよ

696 :669:2012/09/23(日) 09:23:22.14
解決しました。

int64でデータを取得し、上位4バイトの値の有無でOSの32ビット、64ビットを判定することにしました。

お騒がせしました。

697 :669:2012/09/23(日) 09:44:10.40
補足です。

みなさんのアドバイスで、streamからの判断できないことがわかったため、
データ構造から判定することにしました。

4バイトを超えない値が格納されるデータが2連続している場所(OSにより、領域は4*2または8*2バイト使用)があるので、
そこからINT64で取得して上位4バイトの有無を調べます。
※0が格納される事がなく、値が4バイトの範囲内に必ず収まり、2連続しているというデータ上の仕様があったため、可能でした。


698 :デフォルトの名無しさん:2012/09/23(日) 11:35:34.31
int64は32bitOSでも64bit
packしたところで変わらんと思うんだが

699 :デフォルトの名無しさん:2012/09/23(日) 12:58:56.01
32bit Linuxが送ってくる64bitポインタの上位32bitが
必ず0である保証がないと成立しないね。
同様に64bit Linuxが送ってくる64bitポインタの上位32bitが
必ず0以外である保証もないと成立しない。

いろいろ危うい前提条件に立った判定方法だと思う。
設計段階からやり直したほうがよさそう。

700 :デフォルトの名無しさん:2012/09/23(日) 13:37:28.60
まあ本人納得してるんだからいいんじゃね。

701 :デフォルトの名無しさん:2012/09/23(日) 14:46:09.74
問題が起こる前に転職すればいい。

702 :デフォルトの名無しさん:2012/09/23(日) 16:27:26.97
>>699
クライアント側はいじれないって前提読めよ。

703 :デフォルトの名無しさん:2012/09/23(日) 16:40:18.78
その前提があったからといって危ういことに変わりはない。
だとしたらなおさら「それはできません」以外の答えはないと思う。

704 :デフォルトの名無しさん:2012/09/23(日) 16:43:19.60
それがあったので。

705 :デフォルトの名無しさん:2012/09/23(日) 17:19:16.81
>>703
>だとしたらなおさら「それはできません」以外の答えはないと思う。

仕事したことない奴が言うことだな。

706 :デフォルトの名無しさん:2012/09/23(日) 17:33:27.68
ないのは知恵。

707 :デフォルトの名無しさん:2012/09/23(日) 17:39:41.39
保証できない前提条件に基づいたソフトウェアを検収するような
会社ならそれでいいんだろうけどねぇ。

708 :デフォルトの名無しさん:2012/09/23(日) 17:53:46.64
> ※0が格納される事がなく、値が4バイトの範囲内に必ず収まり、2連続しているというデータ上の仕様があったため、可能でした。

どこがご不満で?
xdr streamのごくありきたりな使い方ですが?


709 :デフォルトの名無しさん:2012/09/23(日) 17:54:39.91
保証できない?

> ※0が格納される事がなく、値が4バイトの範囲内に必ず収まり、2連続しているというデータ上の仕様があったため、可能でした。

が、保証されてりゃ十分だろ。

もちろん今後の仕様変更には注意が必要だから、お客さんにはよく言い含める必要はあるけど、
それはまた違う話だしね。

710 :709:2012/09/23(日) 17:56:36.11
被った…

>>708
ありきたりじゃないと思うが…

普通、最初の方にバージョンとか、特性とかの情報を埋め込んでおくのが常套手段と思う。

711 :デフォルトの名無しさん:2012/09/23(日) 17:58:53.02
普通にクライアント側のプログラムは無理して64ビットにする必要ないじゃん。
クライアント側プログラム変更できないのに、なんで64ビットに出来るんだよ。
変更できてるじゃん。

この時点で質問の前提がウソ。

712 :デフォルトの名無しさん:2012/09/23(日) 18:01:29.38
と、意味不明の供述を続けており

713 :デフォルトの名無しさん:2012/09/23(日) 18:45:21.24
>>699
32bit中上8bitとか1bitを別の目的で使っていたシステムみたいだね。
でもint64はポインタじゃないよ?

714 :デフォルトの名無しさん:2012/09/23(日) 18:56:13.96
>>703
システム知らんけど、
64bit側でもint32に入りきる範囲の正の数値しか扱っていない前提なら、
int64でエンコードされていても上位32bitはALL0になるのは保証される

715 :669:2012/09/23(日) 19:37:00.83
混乱させてしまい、申し訳ないです。追加補足します。

・現在、32ビットでサーバ、クライアントが稼働中。クライアント台数多
・ハードウェア老朽化で移行作業をすすめている。64ビットOSに変更
・32ビットOSから64ビットOSに変更する事は決定事項で口を出せる立場にはいない
・稼働中のクライアントプログラムの入れ替えはできない。
・新規に追加されるクライアントは64ビットのOSで追加する。
・最初に更改されるのはサーバ(64ビットになる)

上記の状態で、調査を実施し、一部の通信データでlongが使用されていた。
これは、32ビットと64ビットでサイズが異なってしまうため、32ビット分しか使用されていないか調査した。
※問題なければ、intにキャストして解決しようとしていた。
しかし、全体の中の一部だけOS依存のデータがあり、8バイトになってしまうものがあった。
上記理由のため、64ビット版ではクライアント側、OS側共にlong部分をINT64に変更する必要がでた。

まずはサーバ移行のため、32ビット版だけに対応していれば、すぐには問題がでないが、段階的に64ビットの
クライアントが導入された際に問題がでるため、対応方法を検討していました。
XDRは使用した事がなく、調査したが対応策を発見できなかった為、使用経験がある方からのアドバイスを頂きたく、相談しました。

今回の対応方法はデータ仕様依存があるので、仕様変更された際には保証ができませんが、>>709さんが書いてあるとおり、
現時点では問題ないと認識しています。


716 :デフォルトの名無しさん:2012/09/23(日) 19:44:59.34
まんどくせーけど

ありがちな崩壊しているシステムなのだろう

717 :デフォルトの名無しさん:2012/09/23(日) 19:52:49.27
崩壊してるのはお前の頭。

718 :デフォルトの名無しさん:2012/09/23(日) 20:01:32.51
崩壊しているというか、拡張性を考えていない仕様だったということだろ。

最初の仕様考えた奴が、あまりこういう経験なかったんだろ。

719 :デフォルトの名無しさん:2012/09/23(日) 20:04:22.62
そういうことで崩壊しているといってるのだが

717はデスマでいってよし

720 :デフォルトの名無しさん:2012/09/23(日) 20:34:12.72
ていうか、そもそもプログラムを64bitで動かす必要があるのかどうかが激しく疑問なのだけど。
読んだ限り、「64bitOSにしたから64bit版に変えたい」という以外に見当たらないような。

721 :デフォルトの名無しさん:2012/09/23(日) 20:35:02.73
デスマ助けるのがこういうハックでしょ。
頭固くて馬鹿そうだねえ。

722 :デフォルトの名無しさん:2012/09/23(日) 20:43:00.94
ただで助ける馬鹿がどこにいる

デスマになる理由分かる?

投資労さん

723 :デフォルトの名無しさん:2012/09/23(日) 21:23:03.51
64ビットOS移行は動かせなくても、そのうえで32ビットのクライアントプログラム
動かすのは制約条件に入ってないから全然問題ないじゃん。
必死になってクライアントプログラムの64ビット化進めるメリットなんてまるでない。(営業上の理由?)
アホかと1000回言いたい。

724 :デフォルトの名無しさん:2012/09/23(日) 21:34:14.02
何を必死になってるのか良くわからんけど、メリットなんてよその
人間にわかるわけがない。

営業上の理由かもしれないし、そもそも 64bit 版では 32bit の
プログラムが動かないOSかもしれない。

725 :デフォルトの名無しさん:2012/09/23(日) 21:38:48.39
そうだよ

よそのデスマ、めしうまー

726 :デフォルトの名無しさん:2012/09/23(日) 21:46:11.92
すぐに解決してしまって、何もデスマになってないw

727 :669:2012/09/23(日) 21:52:53.90
なんか燃料投下しているようで申し訳ない。

新しいクライアントの64ビット化に対応するのは必要な部分のみです。

既存で動いているので、基本は新OSで再コンパイルだけで終わらせたいと思っています。

しかし、>>715に記載しているのですが、OS依存のデータが一部あり、OSが変わった事で4バイトだった物が8バイトになってしまったものがあります。
対応しないで4バイトで切り捨てした場合、動作が保証できなくなる不都合があり、必要最低限の対応を行うという物です。


728 :デフォルトの名無しさん:2012/09/23(日) 22:13:26.63
「32bitコードのままではいけない」という理由の説明になってないよ。
具体的に「何が8バイトになったのか」を示さないと。

散々いわれてるけど「64bitOSでも32bitプログラムはそのまま動く(大半は)」ので
いわゆる64bit処理系で起こる「ポインタが64bit」「longが64bit」というのは
「64bitプログラムにしたから起こること」であって
「32bitプログラムのままではいけない理由」にはならない。

729 :デフォルトの名無しさん:2012/09/23(日) 22:18:01.64
もちろん、「命令によりとにかく64bitプログラムにしなければいけない」というのも
十分な理由ではあるけれど、
それなら「OS依存のデータ云々」は関係ないよね。

730 :デフォルトの名無しさん:2012/09/23(日) 22:18:49.64
いいじゃねーか

馬鹿ユーザに馬鹿害虫

731 :デフォルトの名無しさん:2012/09/23(日) 22:32:11.89
馬鹿害虫に想像力がないだけだろ。

例えばそのプログラムが物理メモリーの最大値を返すとか言うのが想像できないんだろ。

※ 一部の 32bit OS では、4GB 以上の物理メモリーをサポートするけど、一例だからね。

732 :678:2012/09/23(日) 22:41:44.12
>>715,727(>>669)
(ネットワーク上を流れる)外部データ表現と(OS内部の)内部データ表現との違いを間違って理解している
XDR(eXternal Data presentation)は通信規格だから、
(一般的な)整数型は(OSの違いとは無関係に)32bit固定と明確に仕様が定義されている
(これはC言語上でのデータ型 short/int/long のどれであっても同じで、通信データとしては全て32bit)
そして、long型のOS内部表現では大きさが32bit/64bitとかエンディアンといった差異が
存在するから、それらを吸収させる為に xdr_xxx という変換関数がライブラリとして提供されている
だから「32ビットと64ビットで(通信データの)サイズが異なってしまう」なんてことはありえなくて、
普通は xdr_long を呼ぶコードには何ら修正を加えること無くリコンパイルするだけで終わる

以下は「Solaris 64 ビット開発ガイド」p.64 からの引用(題名でググればPDFで読める)
  XDR ルーチンの xdr_long(3NSL) は問題と思われるかもしれません。しかし、これは
  既存のプロトコルとの互換性を持たせるために従来どおり 32 ビットとして取り扱われます。
  64 ビットバージョンのルーチンが 32 ビットに格納できない long 値を
  コード化するように要求された場合、そのコード化処理は失敗します。

733 :デフォルトの名無しさん:2012/09/23(日) 23:20:32.49
何を力説してるのか知らんけど、そういう問題じゃないから。

734 :デフォルトの名無しさん:2012/09/24(月) 00:48:10.21
今までの32ビットプログラム/32ビットOSで32ビットで見えていたOSのリソースが
32ビットプログラム/64ビットOSになると64ビット必要になるというのは何だろう。
物理メモリなんてくだらない情報は適当な32ビット値返しときゃいいし。

735 :デフォルトの名無しさん:2012/09/24(月) 05:03:41.05
>>734
> 物理メモリなんてくだらない情報は適当な32ビット値返しときゃいいし。

そんなに悔しかったのかよ (w

736 :デフォルトの名無しさん:2012/09/24(月) 08:19:15.21
>>734
まぁ、手っ取り早く移植したいなら、
typedef int longとでもすれば済む話だしな。

737 :デフォルトの名無しさん:2012/09/24(月) 10:21:12.21
>>736
全ライブラリにそう書いて回るの? 大変だね

738 :デフォルトの名無しさん:2012/09/24(月) 10:44:26.21
includeすればいいだろう

739 :デフォルトの名無しさん:2012/09/24(月) 10:58:58.78
組み込み型をtypedefてw

740 :デフォルトの名無しさん:2012/09/24(月) 11:09:20.02
intをlongにしてgccをrebulidするんだよ


741 :デフォルトの名無しさん:2012/09/24(月) 11:39:38.01
64ビット用のサーバーは32ビット用と分ければいいのではないか
64bitのクライアントは64bitのサーバーに接続する。
なんというすばらしい発想の転換

742 :デフォルトの名無しさん:2012/09/24(月) 12:07:03.60
IPv6 クライアントも IPv6 サーバーにしか繋がらないようにすれば良かったのに

743 :デフォルトの名無しさん:2012/09/24(月) 13:31:21.22
みんなひまだなー

744 :デフォルトの名無しさん:2012/09/24(月) 15:58:49.04
元のデータ構造が
int,long
ごちゃまぜなんじゃね

745 :デフォルトの名無しさん:2012/09/24(月) 16:05:58.57
もう>>741が最強すぎて話にならない

746 :デフォルトの名無しさん:2012/09/24(月) 16:07:36.93
何のためにRPCを使ってるか

747 :デフォルトの名無しさん:2012/09/24(月) 16:18:25.17
ttp://docs.oracle.com/cd/E19253-01/816-3978/6ma7kltoc/index.html
これ使って、ハマらないようにしましょうって、言ってるのもわからないんだ

748 :デフォルトの名無しさん:2012/09/24(月) 22:24:01.45
>>747
>>733

749 :デフォルトの名無しさん:2012/09/24(月) 22:30:52.18
?

750 :デフォルトの名無しさん:2012/09/24(月) 22:32:05.16
高脳の言ってることはよーわからんなあ

751 :デフォルトの名無しさん:2012/09/24(月) 22:50:14.09
一番簡単な方法
逝ってるな64bitOSなら
32アプリが動くような環境作ればいいだけ
移植もへったくれもない

752 :デフォルトの名無しさん:2012/09/24(月) 23:01:13.20
RPCでlongとか使ってるプログラム作った外注か社員は、
速攻追放した方がいいよ。この先もどんどんコストかかるような
バカやらかすよ。

753 :デフォルトの名無しさん:2012/09/24(月) 23:41:32.58
>>751
まだ馬鹿晒すのかよ…

754 :デフォルトの名無しさん:2012/09/24(月) 23:46:02.68
別にバカの自覚あるから、何言われても平気だけど
まともな反論してみな

755 :デフォルトの名無しさん:2012/09/25(火) 00:11:35.99
ネットワーク越しに OS依存のデータを送る/受ける欲求ってありえるの?

756 :デフォルトの名無しさん:2012/09/25(火) 00:18:07.04
盛り上がってるな。
よくわからんが、

struct T { size_t file_size; time_t creation_time };

みたいなレコードをクライアントからサーバに送る処理があって、
32bit OSのクライアントはint32型の値を並べて送ってくるけど、
64bit OSはint64型の値を並べ絵送ってくる。
これをストリームとして受信しているサーバ側で区別したいということかな?

757 :デフォルトの名無しさん:2012/09/25(火) 00:26:34.51
むしろfile_sizeが2^32を超えたとかcreation_timeが2^32を超えたとか
そういう話らしい。
もちろんこの場合は64bitOSとは全然関係ないけれど。

758 :デフォルトの名無しさん:2012/09/25(火) 00:28:47.27
>>752
キャストを間違える、APIの戻り値をハードコードする、
そんなバカな派遣のじじいがいるんだけど、どうやって
追い出したらいいかな。NULLは0だと力説する気狂い。

759 :デフォルトの名無しさん:2012/09/25(火) 00:44:20.50
ハマってる当事者は高度なことやらないといけないと思ってるみたいだね

760 :デフォルトの名無しさん:2012/09/25(火) 01:34:50.39
>>755
SNMP真っ向から否定かよw

761 :デフォルトの名無しさん:2012/09/25(火) 10:58:38.09
>>760
OSには依存してないだろ!

762 :デフォルトの名無しさん:2012/09/25(火) 11:20:51.63
SNMPって、言ってみただけですから

763 :デフォルトの名無しさん:2012/09/25(火) 12:01:11.56
普通にblobやり取りされてるけど…

764 :デフォルトの名無しさん:2012/09/25(火) 13:44:30.77
>>763
それがどうした

765 :デフォルトの名無しさん:2012/09/25(火) 15:02:25.41
"OCTET STRING"くらい知っておこう。

766 :678:2012/09/25(火) 18:48:19.96
>>756
おそらく質問主(>>669)は、そのように考えていたのだと思う

しかし、今回の64bit版サーバ&クライアント開発のケースでは、
・64bit化に伴なう機能の追加や変更は一切無く(>>715,727)、しかも
・整数値は必ず32bitに格納できる(>>679)
わけだから、(>>732で書いたように)クライアントのOSが32bit/64bitのどちらであっても
(XDRでエンコードされて)ネットワーク上を流れる通信データは32bit表現のままで何も問題は無かった

結論としては、32bit版のコード内にある xdr_u_long の部分を「わざわざ」 xdr_int64_t へと
修正したこと(>>669)そのものが誤りであり、その「余計な行為」がバグを作り込んでしまったと言える
言い換えると、既存の32bit版システムで使われていた通信プロトコル仕様における整数表現形式を
32bitから64bitへと「意図せず」に改変(改悪?)したことになる

767 :デフォルトの名無しさん:2012/09/25(火) 22:00:49.15
>>766
余計な行為じゃねーだろ、意図もしてるし。

>>715 全体の中の一部だけOS依存のデータがあり、8バイトになってしまうものがあった。

ただ修正の方法が間違っているとは思う。

>>754
反論なんているか?
普通の頭持ってたら、>>751 が意味ないことがわかると思うんだが…(w

768 :デフォルトの名無しさん:2012/09/25(火) 22:08:57.16
言葉(単語)だけでその先を知らないんじゃねえの?

769 :デフォルトの名無しさん:2012/09/25(火) 22:15:02.31
バカなのは767。
751は正しい。

770 :678:2012/09/25(火) 23:11:09.70
まず、>>766内のアンカに誤りがあったので訂正する
 X: ・整数値は必ず32bitに格納できる(>>679)
 O: ・整数値は必ず32bitに格納できる(>>697)

>>767
>余計な行為じゃねーだろ、意図もしてるし。

他の何人かも指摘しているけど、ネットワーク上を流れる通信データとして
OS依存な表現が必要であるという意図(あるいは事情)が(自分には)想像できない
ありえるとすれば、共用メモリ/ファイル共有/プロセス移送といった分散OS的なメカニズムを
実装するケースがあるけど、はたして>>669担当のシステムがそれに該当するのか疑わしい....

で、もしも通信データとして64bit整数(= XDR規格における hyper整数)が「本当に」必要であったのなら、
正式な手順に従って通信プロトコル仕様を改訂し、その工数を見積もりで計上すべきだったと考える
ここで、プロトコル仕様にプロトコルバージョンの概念が含まれていればアップすることで対応できるし、
もし無ければ新たにポート番号を割り当て、プロトコルバージョンを含む新プロトコルとして扱うことになる

771 :デフォルトの名無しさん:2012/09/25(火) 23:51:32.24
>>769
>>754

>>770
> 他の何人かも指摘しているけど、ネットワーク上を流れる通信データとして
> OS依存な表現が必要であるという意図(あるいは事情)が(自分には)想像できない

表現って何を言ってるのか知らんけど、上にも上げた物理メモリーの容量とかを
サーバーに送るとかは別に珍しくないと思うが。

> プロトコル仕様にプロトコルバージョンの概念が含まれていればアップすることで対応できるし、
> もし無ければ新たにポート番号を割り当て、プロトコルバージョンを含む新プロトコルとして扱うことになる

バージョンがあったらこんなに盛り上がってないし、F/W とかの絡みでポート番号をほいほい
変えられない環境って結構ある。

とにかく、「疑わしい」とか上から目線で語りたいなら、もう少し世間を知った方がいいと思うぞ。
まあ、分散OSって言いたいだけのおこちゃまなんだろうけど。(w

772 :デフォルトの名無しさん:2012/09/25(火) 23:56:59.44
クライアント側が先に作られてしまったけど、立場が弱くてサーバー側からは
直せとは言えないとか、そういうくだらない理由なんだろうな。技術的な話じゃなくて。

773 :デフォルトの名無しさん:2012/09/26(水) 00:04:49.43
32bit用にビルドして動かせば、longだって32bitのままなのに。
え?サーバの64bitの値を取得したいって?
そんなの対応してないから無理。64bitでビルドすればとれるってのは
幻想だよ幻想。

774 :デフォルトの名無しさん:2012/09/26(水) 00:40:37.68
クライアントからデータを送る事例なんじゃないのか?

775 :デフォルトの名無しさん:2012/09/26(水) 00:41:50.75
>>772
て言うか、32bit 版のクライアント配りまくってていまさら入れ替えなんて出来ない状況とかなんだろ。

まあ、それなりにありえる話だと思うぞ。

だからこそ、普通はプロトコルバージョンとかを頭に入れておくとかするんだが、まあ仕様決めた奴が
馬鹿だったんだろうな。

776 :デフォルトの名無しさん:2012/09/26(水) 07:47:24.12
>>771
無能全開で楽しそうだね

777 :デフォルトの名無しさん:2012/09/26(水) 14:57:02.64
逃亡したか。やはりlongとintを区別せずに書いたアプリで32ビットと64ビットが
混乱してるだけなんだろうな。
64ビットOSでも32ビットでコンパイルしたものを動かせば完了だろう。

>>771がファビョってるが、物理メモリ以外の64ビット必要なデータが出てこないな。
ファイルサイズやtime_tは32ビットOSでも既に64ビット化されてるから問題ないし。
物理メモリも32ビットOSでも4G超えてる場合もあったので、今更必死で対応する必要ないな。

778 :デフォルトの名無しさん:2012/09/26(水) 14:58:14.34
>>777
仕事しろ、無能が

779 :デフォルトの名無しさん:2012/09/26(水) 19:38:11.68
>>777
>time_tは32ビットOSでも既に64ビット化されてるから問題ないし。
嘘をつくな!
Linuxの32bit版カーネルではtime_tは32ビットのままだ!

780 :デフォルトの名無しさん:2012/09/26(水) 19:43:20.37
ごめんカーネルじゃないやlibcだった

781 :デフォルトの名無しさん:2012/09/26(水) 19:51:12.85
#define __TIME_T_TYPE __SYSCALL_SLONG_TYPE

782 :デフォルトの名無しさん:2012/09/26(水) 21:02:57.30
>>781
お前馬鹿だろ。9/14のメール読んでみろ。

783 :デフォルトの名無しさん:2012/09/26(水) 21:07:11.50
> 9/14のメール
?

784 :デフォルトの名無しさん:2012/09/26(水) 21:11:59.76
バカじゃないと主張したいらしいが
バカ未満だと認識されてるのもわかってないとか

785 :デフォルトの名無しさん:2012/09/26(水) 21:36:17.95
確かにtime_tはlongのままだね
今更long longにはできんよなぁ

786 :デフォルトの名無しさん:2012/09/26(水) 21:38:30.00
はあ?

787 :デフォルトの名無しさん:2012/09/26(水) 21:39:19.08
あはー

788 :デフォルトの名無しさん:2012/09/27(木) 01:24:15.17
>>776
>>754

>>777
> 逃亡したか。

平日の昼間までにちゃんできるお前に同情してやるよ。

> やはりlongとintを区別せずに書いたアプリで32ビットと64ビットが混乱してるだけなんだろうな。

そんな馬鹿は今時お前ぐらいしかいないよ。
万が一そうだったとしても64bit 版はいくらでも手を入れられるんだから、問題ないし。
そもそも、そういう問題じゃないと >>715 で明記してるし。

> 物理メモリ以外の64ビット必要なデータが出てこないな。

ひょっとして「物理メモリなんてくだらない情報は適当な32ビット値返しときゃいいし。」と言ってた
馬鹿? (w

789 :デフォルトの名無しさん:2012/09/27(木) 01:26:25.40
715で答え書いてるのに今だに悩んでるところがお笑い

790 :デフォルトの名無しさん:2012/09/27(木) 01:30:49.37
webで書かれた手順もへったくれもない方法でやってますって、自白してるんだけどね

791 :デフォルトの名無しさん:2012/09/27(木) 01:36:22.71
64bitのlinux環境だと起動やり直すとメモリ確保した時に同じにならないようになってたような


792 :デフォルトの名無しさん:2012/09/27(木) 11:20:44.30
>>791
32bitでも同じにならないよ

793 :デフォルトの名無しさん:2012/09/27(木) 11:23:04.21
でもあと30年ちょっとで2038年になるんだよな
32ビット版Linuxってそれまでに駆逐されるんだろうか

794 :デフォルトの名無しさん:2012/09/27(木) 11:52:21.29
なくなりはしないと思うけどメモリ拡張に制限はつくし
CPUは例外なく64bit化が完了しているし、プログラム
のバイナリ互換性が問題にならないシステムは順次
64bitに置き換わっていくんじゃないかね。

795 :デフォルトの名無しさん:2012/09/27(木) 12:04:08.34
もう保険やら住宅ローンやらで2038年越えデータもちらほらあるしねw

796 :デフォルトの名無しさん:2012/09/27(木) 15:44:56.98
>でもあと30年ちょっとで2038年になるんだよな

足し算も出来ない知障か
それともこぴぺか

797 :デフォルトの名無しさん:2012/09/27(木) 15:53:26.93
まともにメンテされないOSとその一味でも使ってるのかいな?
お祭り騒ぎにしてひと儲けとかもう無理だから

798 :デフォルトの名無しさん:2012/09/27(木) 17:43:16.91
あと20年は32ビットos残るだろうしなあ

799 :デフォルトの名無しさん:2012/09/27(木) 17:52:18.28
2038年問題は32bitOSがどうのこうのという問題ではない。

800 :デフォルトの名無しさん:2012/09/27(木) 18:00:29.11
20年後は128bit化してるだろ

801 :デフォルトの名無しさん:2012/09/27(木) 18:04:11.15
>NTPやMicrosoft Windowsなど、
>1900年1月1日からの積算秒数で時間を表現するシステムもあり、
>符号なし32ビットの値が2036年2月6日にオーバーフローすることによって
>問題が発生する(→2036年問題)。
64bit長にすれば、なんでもないことでしょ
対応できないようなアプリ作りこむ人達がいるってだけ

NTPはその問題先読みした設計になってたような

802 :デフォルトの名無しさん:2012/09/27(木) 18:05:11.49
20年後なら256bitになってないとおかしい

803 :デフォルトの名無しさん:2012/09/27(木) 18:16:48.23
> 2004年1月10日に「16進数で最初の桁に1が立ち、“負の数”と認識される」(KDDI広報)トラブルが発生した。

804 :デフォルトの名無しさん:2012/09/27(木) 18:25:08.44
16進数というのはネタなのかガチなのか

805 :デフォルトの名無しさん:2012/09/27(木) 18:40:54.89
>>799
linux以外ではね

806 :デフォルトの名無しさん:2012/09/27(木) 18:41:52.10
>>801
最近直した

807 :デフォルトの名無しさん:2012/09/27(木) 18:42:46.75
すべてがFになった

808 :デフォルトの名無しさん:2012/09/27(木) 19:20:54.10
>>804
10進だったらウチでもあったな。
日時順で処理するフラグとしてファイル名にUNIX timeを付けてたら
桁が上がってソート順が変わってしまったw
あれはいつのことだっけ?

809 :デフォルトの名無しさん:2012/09/27(木) 19:27:19.00
3流の釣り師が...

810 :デフォルトの名無しさん:2012/09/27(木) 20:08:44.88
>>808
そんなこともあったねぇ・・・

811 :デフォルトの名無しさん:2012/09/27(木) 20:21:28.92
このころ
http://mimizun.com/log/2ch/accuse/1000000000/

まあ、9が10になったり99が100になったりしたときに
桁数の問題ではなくソート順の問題が出てくるというのも、よくあることだね。

812 :デフォルトの名無しさん:2012/09/27(木) 21:00:19.86
>>807
冷密のきっちりしたロジックのほうがすき!

813 :デフォルトの名無しさん:2012/09/27(木) 22:05:49.10
馬鹿がプログラムしてるからだろう、だったろう

814 :デフォルトの名無しさん:2012/09/27(木) 22:10:47.28
>>812
冷凍庫のぎっしりしたジップロックのほうがすき!

815 :デフォルトの名無しさん:2012/09/28(金) 00:11:00.63
>>790
かわいそうな人…、まあ頑張れよ。(w

816 :デフォルトの名無しさん:2012/09/28(金) 00:36:57.37
別に当事者じゃないから関係ないんだけどね

817 :デフォルトの名無しさん:2012/09/28(金) 01:23:52.66
>>801
>>806
うるう秒の処理にバグがあってシステムごと落ちてたあれか

818 :デフォルトの名無しさん:2012/09/28(金) 20:55:10.72
>>793

819 :デフォルトの名無しさん:2012/09/28(金) 20:59:44.33
>>805
つまりどういうことです?

820 :デフォルトの名無しさん:2012/09/28(金) 22:42:44.91
パソコンを窓から投げ捨てろ
ってこと

821 :デフォルトの名無しさん:2012/09/29(土) 00:47:30.30
ちょっとまって、準備するから

822 :デフォルトの名無しさん:2012/09/30(日) 02:08:50.92
NICの動作モードを取得する方法 (API?) を教えて下さい
知りたいのは半二重、全二重のどちらで動作しているか、です

アダプタの設定ではなく、実際に動作(リンク)しているモードです
Win32_NetworkAdapter classの中には該当するメソッドやプロパティは見当たらないようです

823 :デフォルトの名無しさん:2012/09/30(日) 02:35:34.08
同軸ケーブルな環境でやってるの?

824 :デフォルトの名無しさん:2012/09/30(日) 09:48:11.27
NICのことはNICに聞け

825 :デフォルトの名無しさん:2012/09/30(日) 09:52:34.03
>>823
同軸だったら調べるまでもないだろ

826 :デフォルトの名無しさん:2012/09/30(日) 10:24:36.31
>>822
wmi

827 :デフォルトの名無しさん:2012/09/30(日) 15:27:16.39
半二重、全二重
とかわからなくても、動かす分には関係無いような

828 :デフォルトの名無しさん:2012/09/30(日) 15:58:51.51
>>826
wmiのドキュメントをざっと見てみたのですが、取得の方法がよくわかりませんでした
メソッドの一覧を見た感じ、データリンク層とはあんまり関係ないような気もします

>>827
組み込み制御用のマシンなんですが、全二重になっていないと遅延とデータ量の関係で取りこぼしが発生する可能性があるため
デバッグ用のWindowsマシンを接続した時にNICにモードを自動判別させて、その結果を知りたいのです
スイッチングハブをはさんでLEDで確認するという方法も提案したのですが、できればソフトウェアでやりたいということで

829 :デフォルトの名無しさん:2012/09/30(日) 16:05:08.15
>>828
その馬鹿プログラムを直せよ

830 :デフォルトの名無しさん:2012/09/30(日) 16:09:16.15
だったらオートネゴやめて全二重固定にした方がいいと思うが。

831 :829:2012/09/30(日) 16:27:08.46
>>828
そのマシンの鳥説よめよ

832 :829:2012/09/30(日) 16:46:52.34
というか組み込みプログラムに向いてないからやめたら

833 :デフォルトの名無しさん:2012/09/30(日) 17:16:13.62
帯域絞るときは送信側から送るデータを絞ればいいの?
1Mbpsにしたかったら毎秒1MBしか送信しないようにすればいいの?

834 :デフォルトの名無しさん:2012/09/30(日) 17:20:34.54
受信側を1Mbpsにしても絞れる?
受信側を1Mbpsにしても送信側の帯域はMAXで一気に送信してしまう?

835 :デフォルトの名無しさん:2012/09/30(日) 17:30:59.11
ネット以前に通信の基本的なところからやり直したら

836 :デフォルトの名無しさん:2012/09/30(日) 17:46:07.89
帯域幅ってのはようは平均値だから、大量のパケットの流れとしてみる場合は意味があるが、
個々のパケットのタイミングで考える場合は期間のとり方でいくらでも変わる。
極端には、パケットを送出している範囲に限れば帯域をMAXで使っていることになる。

837 :デフォルトの名無しさん:2012/09/30(日) 20:10:51.17
>>833
YES
>>834
YES

838 :デフォルトの名無しさん:2012/09/30(日) 20:56:45.28
>>822
NDIS対応のEthernetインターフェースならなんとか取得できるだろうけど、
SNMPサーバをたちあげてSNMP経由で取得するのがいいと思う。

839 :デフォルトの名無しさん:2012/09/30(日) 21:18:38.85
LANケーブルの構造も知らんでネット?の事やってるんか?

840 :デフォルトの名無しさん:2012/09/30(日) 21:38:43.85
UTPとか同軸と言わずにLANケーブルと言っている時点で…それ以前にRJ45とかコネクタの問題か。

841 :デフォルトの名無しさん:2012/09/30(日) 21:48:44.10
LANケーブルがmetalとは限らないし

842 :デフォルトの名無しさん:2012/09/30(日) 23:03:00.82
アプリで半二重とかわかったところでなにか変わったことが出来るのかね

843 :デフォルトの名無しさん:2012/10/01(月) 00:18:41.47
わーい、いっぱいつっこまれてる

844 :デフォルトの名無しさん:2012/10/01(月) 00:36:47.54
SNMPてクライアント側でデーモン動いてなくても、通信モードまで取得できたっけ?

845 :デフォルトの名無しさん:2012/10/01(月) 01:11:39.05
なんで、スイッチングハブがあるのか、よーく、考えてみようね

846 :デフォルトの名無しさん:2012/10/01(月) 01:13:13.83
>>844
出直してこい。

847 :デフォルトの名無しさん:2012/10/01(月) 04:03:45.80
ちなみにLinuxだとこんな感じでいいのかな。
$ cat /sys/class/net/eth0/duplex
full

848 :デフォルトの名無しさん:2012/10/01(月) 08:40:00.97
バカな客や営業を納得させるのは面倒だから、データ落ちが起こらないように
きっちりバッファリングする提案(開発費大)と、全二重チェックして半二重だったら
止める(開発費小)を提案して選ばせるのはありかと。

849 :デフォルトの名無しさん:2012/10/01(月) 08:41:28.68
はあああああ?

850 :デフォルトの名無しさん:2012/10/01(月) 08:59:31.30
>>849
わかってないバカがまだいるのか。現実直視しろよ。
開発に求められているのは機能や品質じゃなくて、コストなんだよ。
自分が担当しているうちに問題起きなきゃOK。
最善の解を追及するなんて不可能。つまらない業界に成り果ててる。

851 :デフォルトの名無しさん:2012/10/01(月) 09:18:42.81
無能言い訳は相変わらず、金(通貨)先の発想かよ
問題(課題)に対しての読解力でも磨いたら

852 :デフォルトの名無しさん:2012/10/01(月) 09:20:47.43
半二重を逃げに理由にしたいだけか?
多分、半二重の環境探してみても、見つからんだろうね

853 :デフォルトの名無しさん:2012/10/01(月) 09:24:58.13
金勘定のできない無能は去った方がいいぞ。

854 :デフォルトの名無しさん:2012/10/01(月) 09:25:58.98
カネ勘定だけしか出来ない無能がいっぱいいるのか?

855 :デフォルトの名無しさん:2012/10/01(月) 09:28:22.25
論理的に説明できなくて煽ることしか出来ない無能をスルーするのが正解

856 :デフォルトの名無しさん:2012/10/01(月) 09:33:50.54
質問者は接続中のメディア種別の取得方法を聞いてるだけ。
前提が全く不明なのに、それは正しくないとか金勘定もできないカタワの
公開オナニーほど見苦しいものは無い。

857 :デフォルトの名無しさん:2012/10/01(月) 09:37:38.65
バカにもなりきれん奴が作れるもんってなあに?

858 :デフォルトの名無しさん:2012/10/01(月) 09:38:34.80
windowsなら、レジストリ漁れば、見つかるんじゃね
こんな簡単なやり方も思いつかんの?

859 :デフォルトの名無しさん:2012/10/01(月) 10:08:14.69
金があれば正しく解決できるし
なければ応急処置しかできない

というだけのはなしだろ。むずかしいことじゃない。

860 :デフォルトの名無しさん:2012/10/01(月) 10:14:21.34
おまえの発言いちいちズレてるよな

861 :デフォルトの名無しさん:2012/10/01(月) 10:28:40.89
>>860
どうズレてるのか説明しろ

862 :デフォルトの名無しさん:2012/10/01(月) 10:38:35.99
>>861
>>856を1000回読め
さらにズレてる上に間違ってる
金があれば正しく解決できるとは限らない
応急処置しかできないとも限らない

863 :デフォルトの名無しさん:2012/10/01(月) 10:48:08.89
なんでそんな必死なん?

無駄なことヤメレに対して金出さないバカクライアントが居るから
という状況の説明するのは普通のことだろ...

864 :デフォルトの名無しさん:2012/10/01(月) 10:54:16.45
質問者はプログラムが動かない(データドロップする)言い訳探してるだけでしょ。
あんまり付き合う気にならないけど、引導渡してやるから成仏しろ。

http://itknowledgeexchange.techtarget.com/powershell/network-adapter-speed-and-duplex/

865 :デフォルトの名無しさん:2012/10/01(月) 13:04:08.80
>>864
それって実際の動作モードじゃないじゃん
こんな短いソースなんだから中身読んでから貼れよ

866 :デフォルトの名無しさん:2012/10/01(月) 13:44:48.08
ここで仕事の内容を晒してることもわかってない

867 :デフォルトの名無しさん:2012/10/01(月) 13:54:01.18
>>866
こんな断片情報で仕事の内容とか腹痛い

868 :デフォルトの名無しさん:2012/10/01(月) 13:55:39.39
じゃあ、無能自慢?

869 :デフォルトの名無しさん:2012/10/01(月) 13:57:58.23
ちょうどいい逃避のネタが

かれこれ2時間ぐらい検索してるけど
海外の掲示板なんかを見ても定期的に出てくる話題っぽい
MSの掲示板でも中の人ができないって言ってるけど本当に無理なのか

870 :デフォルトの名無しさん:2012/10/01(月) 14:18:40.03
アプリで半二重っぽいことすればいいだけ
他のアプリがnet使わない条件でね

871 :デフォルトの名無しさん:2012/10/01(月) 15:08:02.39
>>870
ネットワークカードを直接叩くの?

872 :デフォルトの名無しさん:2012/10/01(月) 16:02:19.34
ルーター通るとどうなるか、調べてみたら

873 :デフォルトの名無しさん:2012/10/01(月) 18:48:05.66
>>865
言い訳になるが有線な環境ないんだよ。↓に状態が出るもんだと思い込んでた。
> イーサネット アダプター ローカル エリア接続:
> メディアの状態. . . . . . . . . . : メディアは接続されていません

こんなのが引っかかったが、ドライバ別に取るしかない?
http://social.msdn.microsoft.com/Forums/en-US/wsk/thread/4baaaabb-cc77-4bd0-91da-00dff3792742/

874 :デフォルトの名無しさん:2012/10/01(月) 19:08:10.82
全二重か半二重かを、特定の機器に依存する方法以外で検出するのは無理じゃないの?
だって、2台をつなぐ時でさえ、間にいくつのハブが挟まってるかわからないと思うから。

全二重/半二重の区別は、NICやスイッチ/ハブとの間の個々の区間で
それぞれ個別に設定されているんじゃないかな。
そして、その個々の区間の終端はMACを持ってないものも多いはず。

875 :デフォルトの名無しさん:2012/10/01(月) 20:04:24.66
>>871
フォトカプラとDIOボードを使えば何とかなると思う。

876 :デフォルトの名無しさん:2012/10/01(月) 20:08:13.91
チップからステータス読めば?
intelと蟹の2種類あれば十分でしょ

877 :デフォルトの名無しさん:2012/10/01(月) 20:26:42.00
>>828で組み込み制御と書いているから、peer接続してるかも。運用の人がCAT1のUTPで繋いだ時に検出するとか。UTPの断線で4芯2対として動いた場合とか。
そもそもプロトコルもIPとかじゃないだろうし。

878 :デフォルトの名無しさん:2012/10/01(月) 20:30:09.63
↓NDISのmedia duplex speedって聞いて分からない人はどうしようもないと思ったほうがいい。
上に書いたようにSNMPに頼ってください。

879 :デフォルトの名無しさん:2012/10/01(月) 22:01:34.09
msdnにあった

ttp://msdn.microsoft.com/en-us/library/windows/hardware/hh205390(v=vs.85).aspx

構造体の中に
 NDIS_MEDIA_CONNECT_STATE MediaConnectState;
 NDIS_MEDIA_DUPLEX_STATE MediaDuplexState;
 ULONG64 XmitLinkSpeed;
 ULONG64 RcvLinkSpeed;

ってあるから、これで読み出せるんでね?

880 :デフォルトの名無しさん:2012/10/01(月) 22:35:12.47
ところがチップによってサポートしてたりしてなかったり。
その辺は自力で調べる必要がある。
英語読めない人は不可能と思った方がいい。
もともと3ComとMicrosoftの決めた古い規格なんで。

881 :デフォルトの名無しさん:2012/10/09(火) 17:34:34.65
SO_KEEPALIVEについて教えてください。
サーバ1つでクライアントが複数ある場合
接続してきたクライアントが有効か否かをチェックする為にSO_KEEPALIVEを使用しようと思っています。
SO_KEEPALIVEはサーバで生成したソケットに対して設定すればよいのでしょうか?
それともacceptしてきたクライアントのソケットに設定するのでしょうか?

882 :デフォルトの名無しさん:2012/10/09(火) 17:41:08.52
>>881
アクセプトしたやつにつける

883 :デフォルトの名無しさん:2012/10/09(火) 17:41:39.51
ごめん、両方

884 :デフォルトの名無しさん:2012/10/09(火) 18:35:18.28
>>883
ありがとうございます。
ちなみにクライアント側のconnectするソケットにも設定する必要がありますか?

885 :デフォルトの名無しさん:2012/10/09(火) 19:18:22.85
>>884
KEEPALIVEは、 投げるか投げないか の設定なのよ。

つまり、KEEPALIVE設定した方は切断を検知するけど
KEEPALIVEを設定して無い側は切断を検知しないんよ。

886 :デフォルトの名無しさん:2012/10/10(水) 11:54:26.04
>>885
承知しました。知りたいのはサーバ側なのでクライアント側には設定しないようにします。

KEEPALIVEを設定してみたのですがConnection timed outというエラーが出ます。
開始までを120秒、リトライ間隔を30秒、リトライ回数5回としてやっています。
ネットは常に接続している状態だし、ルータの自動切断する時間よりも短い感覚です。
なぜエラーになるのでしょうか?

887 :デフォルトの名無しさん:2012/10/10(水) 15:20:36.81
>>886
KEEPALIVEを設定しないとちゃんと接続できるのか?

888 :デフォルトの名無しさん:2012/10/10(水) 15:50:00.85
デフォールトの接続タイムアウトはOSによっても異なる

889 :デフォルトの名無しさん:2012/10/11(木) 14:39:27.80
KEEPALIVE設定したからってConnection timed outはないだろう。
なんか間違ってるよ。

890 :デフォルトの名無しさん:2012/10/11(木) 17:44:23.50
>>881
> 接続してきたクライアントが有効か否かをチェックする為にSO_KEEPALIVEを使用しようと思っています。

そのような目的にSO_KEEPALIVEを使うことはできません。
放置されても接続が破棄されにくくすることが出来るだけです。

>>885
何か別のものと間違えてませんか?

891 :デフォルトの名無しさん:2012/10/11(木) 20:16:05.14
必要もないのに接続したままにするなよな

892 :デフォルトの名無しさん:2012/10/11(木) 20:19:16.88
私ら界隈では、むしろいちいち切断する方が異端らしい‥‥医療機器通信関連ですけど

893 :デフォルトの名無しさん:2012/10/11(木) 20:27:09.15
KEEPALIVEを投げる側しか切断を検知できないってのは間違ってないと思うが?

894 :デフォルトの名無しさん:2012/10/11(木) 20:30:40.04
>>893
違います

895 :デフォルトの名無しさん:2012/10/11(木) 20:35:58.52
>>892
そりゃそういう分野だし仕方ない

896 :デフォルトの名無しさん:2012/10/11(木) 20:41:12.42
>>894
どういうふうに違うの?

手持ちのUNIXネットワークプログラミング第2版vol.1 p179には
『本オプションの目的は、相手ホストのクラッシュを検出することにある』
と書いてあるし、実験でも本番でもそういう挙動しかみたことないけど

どこか間違ってたら訂正するので教えてください。

897 :デフォルトの名無しさん:2012/10/11(木) 20:45:35.93
>>894
いや、原理的にさ、パケットを投げてない側は切断を検知しようがないじゃん。

898 :デフォルトの名無しさん:2012/10/11(木) 20:46:22.07
>>897
いいえ。

899 :デフォルトの名無しさん:2012/10/11(木) 21:07:48.47
>>890
>>894
>>898
悔しさは伝わった。

900 :デフォルトの名無しさん:2012/10/11(木) 21:49:04.25
議論が混乱しているみたいなので、整理してみる....

SO_KEEPALIVEの目的は二つある
・APの無通信状態が継続していてもTCPコネクションの自動切断を抑止する
  ==>「放置されても接続が破棄されにくくすることが出来る(>>890)」
・下位層異常を検知してTCPコネクションを自動的に切断する
  ==> 「SO_KEEPALIVEを設定した(投げる)側だけが切断を検知できる(>>885,893)」

つまり、>>890>>885,893の指摘のどちらも「TCPコネクション接続後の自動切断処理」について
話しているから、両者の指摘はともに間違いではない
ただし、今の時代はWAN(広域ネットワーク)でも常時接続サービスが一般化しているから、
前者(>>890の自動切断の抑止)を目的にSO_KEEPALIVEを設定するケースは極めて限られると思う

そして、「TCPコネクション接続時のエラー検知処理」にSO_KEEPALIVEを利用しようという
質問者(>>881,886)の考え方が間違っている(=SO_KEEPALIVEの目的を誤解している)、と言える

901 :デフォルトの名無しさん:2012/10/11(木) 21:51:11.25
>>896
APレベルとホストレベルは区別しましょう、目的は知らんが

902 :デフォルトの名無しさん:2012/10/11(木) 21:53:26.61
>>901
何を言っているの?

903 :デフォルトの名無しさん:2012/10/11(木) 21:54:49.89
>>900
常時接続だからセッションは切断されないって?
そんな認識でよく生き延びてこられたな


904 :デフォルトの名無しさん:2012/10/11(木) 21:57:37.27
APレベルの話なんて誰もしてないけど?

905 :デフォルトの名無しさん:2012/10/11(木) 22:02:03.79
tcpは無通信状態になっても切断しないがデフォなの

906 :デフォルトの名無しさん:2012/10/11(木) 22:04:28.68
>>900
常時接続といっても、みんなNATになって逆に接続の維持を気にしなきゃ
ならん場面が増えたと思う。

907 :デフォルトの名無しさん:2012/10/11(木) 22:31:00.22
>>905
無通信だからって自分でFINを投げることは無い
というところまではその認識で正しいよ

908 :デフォルトの名無しさん:2012/10/11(木) 22:42:38.12
>>905
でもって無通信状態だと、相手が切断している事に気がつかないまま
ハーフオープンと言う状態に陥る場合がある。
これを防ぐためにKeepAliveを使う訳。

909 :デフォルトの名無しさん:2012/10/11(木) 22:49:07.07
単なる無通信なのか相手がFINを投げずに切断の片開きなのかを区別したい と。

910 :デフォルトの名無しさん:2012/10/11(木) 23:04:07.20
>>908
まあ普通に切断してたら気づくけどな。
問題は無作法だったり、相手のホストがダウンしたり、
途中のファイアーウォールが接続を切ったりした場合。

911 :デフォルトの名無しさん:2012/10/11(木) 23:27:58.06
>>909
いや、区別はつくけど、それは重要じゃないかな
とにかく相手と意思が疎通出来なさそうなら切る

912 :デフォルトの名無しさん:2012/10/11(木) 23:32:37.00
>>902
馬鹿は相手にしない

913 :デフォルトの名無しさん:2012/10/11(木) 23:42:49.47
>>911
SO_KEEPALIVEを使うのは、逆にアプリ側でそういったことを意識しないで
楽できるってことだと思うが。

914 :デフォルトの名無しさん:2012/10/12(金) 00:04:32.78
>>913
そのためのKEEPALIVEですね

915 :デフォルトの名無しさん:2012/10/12(金) 00:09:17.88
>>913
馬鹿乙

すべてのアプリに設定するのか

916 :デフォルトの名無しさん:2012/10/12(金) 00:13:49.20
>>915
はぁ?>>913のように楽したいアプリだけ設定すりゃいいだろ?

917 :デフォルトの名無しさん:2012/10/12(金) 00:19:31.13
>>916
わりい馬鹿だと思ってすべった

918 :デフォルトの名無しさん:2012/10/12(金) 12:47:17.71
>>887
LAN環境なら接続を維持しています。

インターネットだとルータを通り、ルータには無通信状態のタイムアウトが
あるのでそれで切断されているようでした。
なのでKEEPALIVEを設定しています。


919 :デフォルトの名無しさん:2012/10/12(金) 20:45:11.15
>>918
で目的は何?

920 :デフォルトの名無しさん:2012/10/12(金) 21:17:31.93
>>919
・無通信状態によるルータの切断を防ぐ
・接続断を早期に検知する
だろ

921 :デフォルトの名無しさん:2012/10/12(金) 21:18:08.09
これをアプリ層でやるのも面倒だからKEEPALIVEでやるのは
有田と思うよ

922 :デフォルトの名無しさん:2012/10/12(金) 21:57:49.01
>>920
KeepAliveのデフォルト監視周期って2時間だろ。

>・無通信状態によるルータの切断を防ぐ
>・接続断を早期に検知する

上のような目的で、使い物になるの?

923 :デフォルトの名無しさん:2012/10/12(金) 21:59:28.47
>>920
おまえは881か?

924 :デフォルトの名無しさん:2012/10/12(金) 22:13:00.33
>>922
デフォルトのママ使って無いじゃん
>>886見る限り変更してる

925 :デフォルトの名無しさん:2012/10/13(土) 17:18:58.87
>>922
> KeepAliveのデフォルト監視周期って2時間だろ。

そんな長いか?
15年ぐらい前にネットワーク対応の機器の開発やってた時は数分だったと思ったが。

そもそもディフォルトってなんかで決まってるのか?
決まってるなら、ソースよろ。

926 :デフォルトの名無しさん:2012/10/13(土) 17:53:29.63
ディフォルトにすげー違和感

927 :デフォルトの名無しさん:2012/10/13(土) 17:59:27.90
で、このスレに来てるのに>>1のFAQを全然読んでない、と。

2時間というのは決まっているわけではないけれど、ちゃんと根拠があり
少なくともFAQが書かれた当時には、ほぼ全ての実装がそうなっていた、と書いてある。
(SVR4.2も「変更可能である」というだけで「2時間ではない」とはなってない)
http://www.kt.rim.or.jp/~ksk/sock-faq/unix-socket-faq-ja-4.html#ss4.7

928 :デフォルトの名無しさん:2012/10/13(土) 19:17:22.40
>>925
Linux使ってるなら、
/proc/sys/net/ipv4/tcp_keepalive_time
を見るといいよ

そういえばこれipv4なのな。ipv6ではどうなんの?

929 :デフォルトの名無しさん:2012/10/13(土) 20:10:44.25
>>925
RFC1122
4.2.3.6 TCP Keep-Alives
This interval MUST be configurable and MUST default to no less than two hours.

930 :デフォルトの名無しさん:2012/10/13(土) 21:43:52.34
何も考えないやつがnop送りまくらないように2時間以上にしとけってことか?
使うときは短くして使っていいんだよな。

931 :デフォルトの名無しさん:2012/10/13(土) 21:56:01.70
自由に出来るならどうぞ。
システム全体でしか変更できないOSがほとんどだけどね。

932 :デフォルトの名無しさん:2012/10/14(日) 15:30:42.51
ブロードキャスト指示型ワームってアイディアは良いよね
昔からあるんだろうけど何で警察はノーマークだったんだろ

933 :デフォルトの名無しさん:2012/10/17(水) 14:07:10.15
質問です。
socketプログラムでselectを使用して送信可能か判断をしています。
FD_ISSETを判定して送信となった時sendで送信しますが、このsendはfor文で複数回呼んでもいいのでしょうか?
socketはブロッキングモードです。

934 :デフォルトの名無しさん:2012/10/17(水) 15:00:03.99
>>933
送信不可になった時点でブロックされるから大丈夫

「私ならブロッキングモードは使わない、絶対に。」

935 :デフォルトの名無しさん:2012/10/17(水) 15:04:22.63
絶対ニダ

936 :デフォルトの名無しさん:2012/10/17(水) 17:47:04.70
そうだね

937 :デフォルトの名無しさん:2012/10/18(木) 11:17:34.83
>>934
ということはブロックされたくないなら複数回呼んじゃ駄目ってことですね。

ノンブロッキングモードならsendする時selectを使う必要ないんでしょうか?

938 :デフォルトの名無しさん:2012/10/18(木) 11:51:38.24
ノンブロッキングモードなら、sendしてもブロックされず、今は送信できませんエラーが返されるので、送信できるようになってから改めてsendを呼ぶ

939 :デフォルトの名無しさん:2012/10/18(木) 13:59:18.49
>>938
承知しました。selectじゃなくsendの返り値で判断するんですね。ありがとうございます。



940 :デフォルトの名無しさん:2012/10/18(木) 15:09:42.34
sendの返り値でも判断できるしselectでも判断できる
送信できるまで何度も繰り返しsendを呼びまくるのは効率悪いから普通はselect(とかpollとか)で待つけど、まぁ好きにすれば

941 :デフォルトの名無しさん:2012/10/18(木) 15:32:01.00
selectで送信可能になるまで待ち、
sendで送信できる分だけ送信し、
送信し切れなければまたselectで待つ

国家も同じだ

942 :デフォルトの名無しさん:2012/10/18(木) 15:47:00.79
キューが空ならsendで送信し、
 送信できなければキューに入れselectで送信可能になるまで待ち、
 selectで送信可能になったら、キューからsendで送信できる分だけ送信し、
 送信し切れなければまたselectで待つ

キューが空でなければキューに入れ、selectで送信可能になるまで待ち、
 selectで送信可能になったら、キューからsendで送信できる分だけ送信し、
 送信し切れなければまたselectで待つ


943 :デフォルトの名無しさん:2012/10/18(木) 19:40:28.55
>>940
>>941
>>942
承知しました。
ブロッキングモードだと送信できませんエラーが返らずブロックするから駄目
って事ですよね。
ノンブロッキングにして教わったようにやってみます。ありがとうございました。

944 :デフォルトの名無しさん:2012/10/18(木) 22:54:44.45
ばか

945 :デフォルトの名無しさん:2012/10/23(火) 21:05:20.89
じじ

946 :デフォルトの名無しさん:2012/10/23(火) 21:51:04.58
ずず

947 :デフォルトの名無しさん:2012/10/25(木) 19:30:40.15
TCPのサーバプログラムでlistenした後、ノンブロッキング設定しました。
acceptで得られる接続してきたクライアントのソケットにもノンブロキッングモードを設定してやる必要がありますか?



948 :デフォルトの名無しさん:2012/10/25(木) 20:09:57.80
>>947
listenソケットはどうでもいい
acceptしたソケットをこそノンブロックにしろ

949 :デフォルトの名無しさん:2012/10/26(金) 11:41:35.49
>>948
承知しました。ではacceptで得られるソケットに設定します。
ありがとうございます。

もう一つ質問なのですがノンブロックの場合でデータが無い場合、EAGAINが返ってくるとありますが
それでデータの有無をチェックできるならselect要らないのではと思ったのですが必要でしょうか?

950 :デフォルトの名無しさん:2012/10/26(金) 11:54:22.09
データが来るまで何千回だろうと何万回だろうとCPUぶん回して繰り返しrecvを呼び続けるというつもりなら要らない

951 :デフォルトの名無しさん:2012/10/26(金) 12:15:28.13
ビジー・ウエイト/busy waitでググると良い。

952 :デフォルトの名無しさん:2012/10/26(金) 12:22:09.38
>>949
そのためのselectです

953 :デフォルトの名無しさん:2012/10/26(金) 13:28:44.17
selectの返り値でテータがあるか先に判断できるから複数あるソケットを
毎回ループしてチェックする必要がないという事ですね。ありがとうございました

954 :デフォルトの名無しさん:2012/10/26(金) 19:36:21.50
いや、複数のイベントを「待つ」ためのものだが…

955 :デフォルトの名無しさん:2012/10/26(金) 20:37:36.69
サーバプログラムでacceptしてきたソケットをノンブロッキングにしています。
ネットの回線を切断して、サーバからクライアントにデータをsendしても
recvにエラーが返ってこなくなったのですが、どうやって切断の検出をすればいいのでしょうか?



956 :デフォルトの名無しさん:2012/10/26(金) 21:01:46.19
>>954
誤解だぜ・・・ n個のイベントを待つんだよ。

もちろん、0個のときだってある。

957 :デフォルトの名無しさん:2012/10/26(金) 23:06:32.84
>>955
環境に依存しないのはタイムアウトぐらいしかないんじゃね?

>>950
わざわざカッコつけてるんだから、複数に力点がないことぐらい理解できるようになろうよ…

958 :デフォルトの名無しさん:2012/10/27(土) 17:51:49.30
>>955
TCP keepalive あたりでググれば幸せになれるかも


959 :デフォルトの名無しさん:2012/10/28(日) 00:10:16.44
初歩的な質問なんだけど、LAN内端末間通信ってIPアドレスとポートさえ分かれば特に何もしなくてもUDP通信できる?
struct sockaddr_in sock;
sock.sin_family = AF_INET;
sock.sin_addr.s_addr = inet_addr("127.0.0.1");
sock.sin_port = htons(12345);

C言語LINUXだけど、ここのIPアドレス部分にプライベートアドレス(111.111.111.111とか)書いても送れる?

960 :デフォルトの名無しさん:2012/10/28(日) 02:20:18.44
何かしらしなければならない。
開けたり閉じたり書いたり読んだり。
特に何もしなくても通信できるとしたら、神からの啓示だ。

961 :デフォルトの名無しさん:2012/10/28(日) 06:01:14.75
>プライベートアドレス(111.111.111.111とか)

えぇっ!?

962 :デフォルトの名無しさん:2012/10/28(日) 09:07:47.10
>>959
まずは、やってみなよ。

963 :デフォルトの名無しさん:2012/10/28(日) 11:51:41.32
どこの銀河系のIPアドレス空間だ?

964 :デフォルトの名無しさん:2012/10/28(日) 12:26:55.77
こんなスレに来るんなら、nslookup の使い方ぐらい覚えろよ

C:\>nslookup
Default Server: local.gateway
Address: 192.168.1.1

> set type=PTR
> 111.111.111.111
Server: local.gateway
Address: 192.168.1.1

Non-authoritative answer:
111.111.111.111.in-addr.arpa name = KD111111111111.ppp-bb.dion.ne.jp

965 :デフォルトの名無しさん:2012/10/28(日) 13:52:20.65
digすすめろよ

966 :デフォルトの名無しさん:2012/10/28(日) 14:52:28.99
このHPの画像をC#等で取得したい。


isikawahuryouさん

このHPの画像をC#等で取得したい。

http://www.jartic.or.jp/ext_map.html?code=2001

このページになります。
ソース上でGIFファイルのファイル名が特定されていません。
いかがでしょうか。


967 :デフォルトの名無しさん:2012/10/28(日) 15:13:41.30
>>966
取得できないようにがんばっているので
取得しないであげてください。
取得できる方法が確立されたら、
ほかの方法でさらに取得できないようにするだけです。

968 :966:2012/10/28(日) 15:27:28.50
>>967
えっ、そうなんですか?
僕は、このサイトのGIFフィアルを定期的に取得して、
何曜日の何時頃、どこが混むのか知りたいのです。

969 :dummy=0.969:2012/10/28(日) 16:52:44.28
Web製作板に行くとよい。

970 :デフォルトの名無しさん:2012/10/28(日) 16:53:53.47
Firefox だと firebug
IE9 だと F12
で判る

971 :デフォルトの名無しさん:2012/10/28(日) 17:01:22.43
city_highway/rmp200101/rmp200101.gif?dummy=は適当に変えるのが良さそう

972 :966:2012/10/28(日) 17:14:19.34
うはー、やっぱりこの時間になると混んできますね・・・

973 :デフォルトの名無しさん:2012/10/28(日) 17:25:41.59
ティクピッピ ならできるぜ

974 :デフォルトの名無しさん:2012/10/28(日) 23:20:48.48
>>958
キープアライブ実装で出来ました。ありがとうございます。
確認なのですが、ノンブロッキングでsendしてもエラーが返って来ないのは仕様ですか?
今まではキープアライブの変わりに一定間隔でダミーパケットを送信していたもので…

975 :デフォルトの名無しさん:2012/10/29(月) 08:39:47.59
>>966-973
引数つけてるのは取得できないようにしてるんじゃなくキャッシュ回避だろ
定期的に保存したいなら時間情報使って保存ファイル名指定しろ

#数字には意味は何もない
url: "_json/map_" +_jsmode +".json?dummy=" + Math.random(),

976 :デフォルトの名無しさん:2012/10/29(月) 10:52:05.84
マップの url は
/map/city_highway/rmp200101/rmp200101.gif?dummy=毎回異なる値
そのマップの時間は
/_json/map_city_highway_2001.json?dummy=毎回異なる値
で返ってくる JSON の viewdata[2001]['updtime']

977 :デフォルトの名無しさん:2012/10/29(月) 11:46:09.31
>>974
ノンブロックの時、回線切断状態の時にsendしても
recvにエラーが返ってこないのは仕様ですか?の間違いです。

978 :デフォルトの名無しさん:2012/10/29(月) 11:58:58.67
接続が切れたかどうかはわからないのが分散環境の基本。


979 :デフォルトの名無しさん:2012/10/29(月) 12:09:40.66
>>977
普通に返ってくるだろ
まだ送信リトライしてる最中だろうから待てよ

980 :デフォルトの名無しさん:2012/10/29(月) 12:12:32.37
必ず返ってくることを期待してプログラム書いてたり
タイムアウトの見切りが異常に遅い糞プログラム書いてると
Windows Vista / 7 の exoplorer のようになります

981 :デフォルトの名無しさん:2012/10/29(月) 13:02:09.11
承知しました。ありがとうございます。
sendでさらに質問なのですが
複数あるクライアントの1つのソケットでsendがもう送れませんってエラーを返したら
他のクライアントにも送れないのでしょうか?


982 :デフォルトの名無しさん:2012/10/29(月) 19:07:09.18


983 :デフォルトの名無しさん:2012/10/30(火) 00:14:17.97


984 :デフォルトの名無しさん:2012/10/30(火) 00:26:25.70


985 :966:2012/10/30(火) 01:48:38.79
>>975-976
すみません、さっぱりわかりません。
もう少し噛み砕いて教えていただけないでしょうか。

986 :デフォルトの名無しさん:2012/10/30(火) 20:21:00.01
落ちるで

987 :デフォルトの名無しさん:2012/10/31(水) 04:47:20.22


988 :デフォルトの名無しさん:2012/10/31(水) 10:21:43.43
>>985 「さっぱり」わからんなら少しはわかるまで自助努力したらどう?

989 :デフォルトの名無しさん:2012/10/31(水) 10:37:11.03
>>988
うるさい黙れ

990 :デフォルトの名無しさん:2012/10/31(水) 10:59:32.55
>>988
謙遜してるだけだろ
あの説明をあれ以上噛み砕いたら何も残らんよ

991 :デフォルトの名無しさん:2012/10/31(水) 11:05:49.33
さっぱり噛み合ってない

992 :デフォルトの名無しさん:2012/10/31(水) 12:23:35.57
噛み合せは大事だよ

993 :デフォルトの名無しさん:2012/10/31(水) 12:24:24.49
それが、プロトコル

994 :デフォルトの名無しさん:2012/10/31(水) 15:42:28.30
やり方そのもの書いてあるのにそれが「さっぱり」わからんようなの人間ですらないわ

995 :デフォルトの名無しさん:2012/10/31(水) 15:49:30.25
おしえてくんのコピペに「さっぱり」の例があったなw

996 :デフォルトの名無しさん:2012/10/31(水) 16:18:45.50
噛んで噛んで

997 :デフォルトの名無しさん:2012/10/31(水) 16:37:10.54
回って回って

998 :デフォルトの名無しさん:2012/10/31(水) 16:39:52.06
梅の季節

999 :デフォルトの名無しさん:2012/10/31(水) 17:05:40.08
ネットワークプログラミング相談室 Port29
http://toro.2ch.net/test/read.cgi/tech/1351670708/

あとたのむ

1000 :デフォルトの名無しさん:2012/10/31(水) 18:24:48.59
Linuxがインターネットを作った。
Windowsは出て行け。

1001 :1001:Over 1000 Thread
このスレッドは1000を超えました。
もう書けないので、新しいスレッドを立ててくださいです。。。

231 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.02.02 2014/06/23 Mango Mangüé ★
FOX ★ DSO(Dynamic Shared Object)