nakaji です。ちょっと逸脱しているかも、知れませんが.....。 >>ＴＣＰ／ＩＰのプロトコルの実装で、情報交換等できましたら、と思っています。 >>宜しくお願いします。 >> >>ｍａｕｍさんも読んでますかー！ >> >> >読んでます、読んでます。ちょっと今考えていることをざっくり書いて見ますね >長文ですいません。 > > >ＴＣＰ／ＩＰの実装で問題なのは今のところ２点あります。 >１つは以前にhamayanさんがおっしゃっていたウィンドウ制御、 >それとパケットの並べ替えです。 >どちらもサーバー、クライアントが通信状態になってからの >制御になると思います。 >以下、私の頭の中にある考え方を記述しますので間違えていたら指摘してください。 >ＲＦＣを読破しているわけじゃないです。 > >んじゃ、まずウィンドウ制御から話題にして・・・ >ＴＣＰはスライディングウィンドウですから、送り先は勝手にパケットを >いくつか送れますよね。（ＴＣＰはコネクションを張る前にセグメントの >ネゴシエーションをして１パケットがセグメントを越えて転送されることはない。 >普通は0x5b4(1460)に設定されることが多いようです。） >で、たとえば受信バッファに4KB割り当てたとするとウィンドウサイズは >0x1000になりますよね。そこまではいいのですけど >相手からのパケットが来て、自分がackパケットを送信しようとしている最中に >さらに相手からパケットが来てしまったということが発生しうるわけで >そうした場合、相手に対して自分のウィンドウサイズを通達するタイミングを >逃してしまうじゃないですか？ >それとも、送信側は相手（受信側）のウィンドウサイズを知っているわけで >すから、その範囲内でパケットを連続して送ってくるのですかね？ > > >次にパケットの並び替えです。 >これは落ち着いて考えれば何とかなりそうなんですけど、 >要するにルーターを通ったときにその時々でルーティングが変わった場合 >分割されたパケットが順番どおりに届かない可能性があるわけで >それをＴＣＰヘッダー内のシーケンス番号順に並べ替えてやる >ことですよね。この場合の並べ替え用のバッファサイズって >やっぱりウィンドウサイズと同じでいいのでしょうか？ > >運良くパケットが全部そろえばいいですけど、ロストする可能性だって >あるわけで、一体何秒待つのが妥当な数字なの？ >とか、実装するには課題が一杯あるんで乗り上げてます。 > > > 私も以前、スライディング・ウィンドウで悩んだことがあります。手元にＲＦＣ 等資料がないので、正しいとは、言えませんが、 確か、スライディング・ウィンドウの場合、ネゴシエーションが成立している場 合にスライディング(?)するんじゃなかった かとおもいます。だからＡＣＫのあと、スライディングしたパケットが送信され てきても、データサイズ(バッファ)は既知のはずなので、OKなはず。逆にＮＧ だった場合には、元のパケット・サイズにて、再送信されるはずだったような... となると、ウィンドウサイズ=バッファサイズというのが、正解だとおもいます (生成規則までは覚えていないですが) あと、パケットの並び替えですが、確か、待ち時間= 2MSL + 2MSL x( ホップ数- 1) ってどっかにあったような..... あやふやですいません。
