08/06/17 04:08:33
>>372
I/Oだったら普通にキューにぶっこんでコンテキストスイッチしないかな？
379:デフォルトの名無しさん
08/06/17 04:28:02
Winsockでconnect､send､recvそれぞれに個別のタイムアウト値を持たせたいのですが、
connectのみ
WSAWaitForMultipleEventsでタイムアウトを判断して
send､recvはsetsockoptを使って指定、
これで大丈夫でしょうか？
380:デフォルトの名無しさん
08/06/17 08:52:26
今の今までスレタイがtypoだと思ってた俺愕然。
381:デフォルトの名無しさん
08/06/17 09:58:45
65535まで続くよ！
382:355
08/06/17 10:05:16
>>367
シングルスレッドの場合でしょ、それは絶対にあり得ないと思うんだけど。
最近のカーネルは、カーネルプリエンプションだから、カーネル内部の処理
実行中にコンテキストスイッチすることもあるかも知れないけど、
ロジックの実行順序(逐次処理)が入れ替わることはないと思います。
>>373
それとはまた別の話ではないでしょうか。
sendを呼んだひとはブロックされるでしょうが、他のプロセスは
普通にシステムコールを実行することも、ユーザーランドのロジックも
実行できると思います。
>>374
私もそういう認識です。
TCPで１つのスレッドが送信した場合であれば、sendした順に相手側では
recv出来ると思ってます。(何回recvすれば良いかは判らんけど。)
途中でパケロスしたり、物理的に線が切れたりした場合は、受信側に届いた
部分まで(これも、相手がsendした順)が受信出来る。
なにか間違ってます？ >> all
383:デフォルトの名無しさん
08/06/17 16:49:35
>>479
384:デフォルトの名無しさん
08/06/17 17:04:56
>>379
385:デフォルトの名無しさん
08/06/17 17:14:26
>>579
386:デフォルトの名無しさん
08/06/17 17:23:55
getaddrinfoはブロッキングを起こしますか？
387:デフォルトの名無しさん
08/06/17 17:54:23
AI_NUMERIC を付けない場合は起こします
388:デフォルトの名無しさん
08/06/17 18:07:41
LAN接続PC間で、低速、高ping回線の環境を再現するにはどのような方法があるでしょうか？
自作の俺プロトコルアプリが低速回線環境でどういった影響を受けるのか調べたいのですが。
環境はWindowsです(98orXP)
389:デフォルトの名無しさん
08/06/17 19:19:43
そういうソフト使えばいいだろ。
390:デフォルトの名無しさん
08/06/17 19:50:44
>>367
TCPでそれがあったら大変だろ
ＵＤＰでは十分ありうるだろうが
ＵＤＰは順序がかわるどころか
複製されたりもするらしいからな
しかしＵＤＰって順序も保障されてないとなると
１パケットあたりの情報をどうやって認識するんだろうか
区切り文字やらパケットサイズ送っても
順序がかわったりしたらアウトだよな？
391:デフォルトの名無しさん
08/06/17 20:41:21
このスレに出入りする奴の発言とは思えんな。
392:デフォルトの名無しさん
08/06/17 21:56:19
UDPは来るか来ないかだけで、「パケット」という構造自体は保証されるだろ。
２つ以上のパケットをもってきて、その関連をどうこういうと面倒だけど。
393:デフォルトの名無しさん
08/06/18 09:28:59
UDPで順序が変わるってのはわかります。
例えば、
(1)udp_send("ABCD");
(2)udp_send("abcd");
とした場合、(1)で作成されたUDPパケットが相手HOSTに到達
するルートと、(2)で作成されたUDPパケットが相手HOSTに到達
するルートが同じだとは限らないですよね。
たまたま、(２)のUDPパケットが相手HOSTに到達するルートの方が
速い回線だったりした場合、受信側のHOSTでは、(２)(１)の順に
UDPパケットを受信する事もあり得ます。
UDPパケット毎の順序は不定ですが、複数のUDPパケットが混ざる
事はありません。(シングルスレッドの場合)
で、複製されるってのはどういう意味？
394:デフォルトの名無しさん
08/06/18 17:14:46
udp_send("ABCD");
とかが２回以上あったかのように
複数回届くことかと思われ
で、実際そういうことがある
パケットにインデックスとかつけて
２回目以降のやつは棄てればいいので問題ない
395:デフォルトの名無しさん
08/06/18 17:22:56
>>394
それって UDP側じゃなくて MAC側の仕様じゃないの？
結果は同じだけど・・・
細かすぎるか？ｗ
396:デフォルトの名無しさん
08/06/18 17:48:55
UDPパケットがネットワーク上で消失するってのは判るんですが、
重複するってのはなぜ？
誰がパケットを複製するの？
マルチキャストであればルータがパケットを複製するってのは
判るんですが。
397:デフォルトの名無しさん
08/06/18 17:59:51
論理的にはあり得ないけど、ハードやOS側が腐っている場合は、
勝手に複製されてしまうこともあるって事ですか。
man ping より
重複パケットと障害パケット
ping ユーティリティは重複パケットと障害パケットを報告します。重複パケット
はユニキャストアドレスに対しては起こるはずのないものですが、リンク層での
不適切な再送信によって引き起こされるようです。重複は様々な状況で起こる可
能性があります。低いレベルの重複の存在は必ずしも警告にならないかもしれま
せんが、よい兆候ではありません。ブロードキャストもしくはマルチキャストア
ドレスに ping する時には、重複が起こることが期待されます。実際に重複する
のではなく、異ったホストから同じ要求に対して応答が行われからです。
障害を受けたパケットは明らかに重大な警告です。多くの場合、ping パケットの
経路のどこか (ネットワーク内かホスト内) のハードウェアの故障が考えられま
す。
398:デフォルトの名無しさん
08/06/18 18:03:13
よって、パケットの複製は、UDPだから発生するとかって話では
ないってことですね。
ただ、TCPだと、勝手に捨ててくれるけど、UDPだとそのまま
複数回受信しますということね。
と、なっとくしました。
考え方が間違ってたら、指摘してもらえると嬉しいです。