08/12/25 21:57:32
UDPは何も言わずに捨ててよい
895:デフォルトの名無しさん
08/12/25 21:58:34
UDPはアプリの方で管理
896:デフォルトの名無しさん
08/12/25 22:04:02
パケットの消失は、基本的にはルータやエンドで処理しきれず捨てられるか、寿命が尽きるかのどちらか。
sendしたパケットが相手に届いてちゃんと受けとればけば、recv使用がしなかろうが、TCPのバッファには残る。
897:デフォルトの名無しさん
08/12/25 22:13:26
最近はファイヤーウォールももみ消すよ。
>>893
ICMPもなくなる可能性があります。
基本的に、パケットがなくしてしまってもいいから、
どんどんネットワークをつないでいくってのがInternetの設計方針。
送信保証はエンドツーエンドでやる。つまりサーバとクライアントの仕事。
なくしていいよってことを認めないと、
PC買ってきて家ですぐにつなげなくなる。
電話みたいにISPのルータでの設定が必要になってしまう。
そういうネットワークはみんな滅亡した。
自分でやるのが面倒なプログラマはTCPを使うべき。
まともな再送機構作るのはかなり難しい。
898:デフォルトの名無しさん
08/12/25 22:26:37
UDPは消える
ヤバイくらい消える
ローカルなネットで２台しか繋がっていないテスト環境でも消える
っつーか取りこぼす
899:デフォルトの名無しさん
08/12/25 22:29:10
そりゃ送りすぎなんじゃないの？
900:デフォルトの名無しさん
08/12/25 22:30:39
でも最近では、バルクデータもUDPで送るようなソフトが出てきてるよな。
SINET等の高速回線ではそのほうがいいらしい。
901:デフォルトの名無しさん
08/12/25 22:33:22
>>900
> SINET等の高速回線ではそのほうがいいらしい。
TCP実装するくらいの実力があればね。
902:デフォルトの名無しさん
08/12/25 22:46:56
URLﾘﾝｸ(d.hatena.ne.jp)
903:デフォルトの名無しさん
08/12/25 23:16:05
みんなクリスマスの夜だというのに饒舌だなぁ。
もういいから彼女の元に戻ってやれよ
904:デフォルトの名無しさん
08/12/25 23:53:05
>>901
imihumei
905:デフォルトの名無しさん
08/12/25 23:55:33
状況によりけりだろうな。
ＳＩＮＥＴでもノードによっては遅延がでかいし。
906:デフォルトの名無しさん
08/12/26 03:47:52
UDPの方が意図通りに組める
907:デフォルトの名無しさん
08/12/26 05:00:00
新規にブラウザのレンダリングエンジンを作りたいんですけど、
とりあえず何が難しいのか分からない
908:デフォルトの名無しさん
08/12/26 05:15:35
ですよねー
909:デフォルトの名無しさん
08/12/26 06:24:24
彼女いないし
910:デフォルトの名無しさん
08/12/26 09:25:06
>>907
頼もしいな。
911:デフォルトの名無しさん
08/12/26 16:01:10
>>898
それは単に送りすぎなだけだよｗ
通信対戦ゲーム作る時、いろいろな環境で実験したが
時々ごっそり消える（しばらく通じなくなる）が、普段は快適。って結果だったな。
最初ネットで拾ってきたテストコードでやったらごっそり消えまくって、UDPひでえって思ったけど、
単にそのテストコードがデータ送りすぎなだけだった。
912:デフォルトの名無しさん
08/12/26 16:29:43
データ送りすぎもいいけど、それはOSやルータ側が処理しきれないで破棄するっていう問題なのか、それともUDPの仕様（の限界）なのかってことじゃないのか？
極端に言えば「処理できるのは１秒に１パケットだけだからそれ以外は破棄よ」ってこともありえる（例えば同期の問題とかで）。
913:デフォルトの名無しさん
08/12/26 16:33:49
送りすぎってのは一回の送信で沢山送ろうとしてるだけなんでは？
それならバシバシ消えると思う
914:デフォルトの名無しさん
08/12/26 20:55:05
ビジーループみたいなループの中で１００バイトのパケットを送り続けるとかやったんでしょ？
テストコードとしてはやりがちだからね。
でもこれだとポロポロ落ちるんじゃね？
スリープ入れないと。