お世話になっています。hamayan です。 すいません、私もＲＦＣなんて全然読んでいないし、今会社で、手元に教科書 が無いので取りあえず、ＵＮＩＸネットワークプログラミング ｖｏｌ２から読 み取った所を書きます。 送信に対する応答をどれ位待つか？ですが、応答が無い時は再送し、普通は４分 から１０分で諦める、但し、ＴＣＰは、クライアントとサーバー間の往復時間を 動的に予想するアルゴリズムを内蔵している！と書かれています。 ４分や１０分も待てないけれど、再送時間を動的に予想するのもしんどいですね。 特に、ＷＡＮに対する送信の場合、間隔が短ければ、輻輳になってしまう。 次に、ウインドウサイズですが、ＴＣＰは相手に対して、自分が何バイトのデータ を受け取る準備があるかを、常に通知している。となっているので、送り側は、 受け側がオーバーフローする複数のパケットを送ってはやはりいけないのでは ないでしょうか。 受け側が、確認応答番号と一緒に、ウインドウサイズを再度通知し、送り側は、 それを元に、一度に送れるパケットの数を、再設定する。感じでしょうか。 maum> ネゴシエーションをして１パケットがセグメントを越えて転送されることはない。 maum> 普通は0x5b4(1460)に設定されることが多いようです。） maum> で、たとえば受信バッファに4KB割り当てたとするとウィンドウサイズは だから、この場合２セグメントになりますか。 maum> 0x1000になりますよね。そこまではいいのですけど maum> 相手からのパケットが来て、自分がackパケットを送信しようとしている最中に maum> さらに相手からパケットが来てしまったということが発生しうるわけで maum> そうした場合、相手に対して自分のウィンドウサイズを通達するタイミングを maum> 逃してしまうじゃないですか？ ＴＣＰは全二重で通信できるので、その時点のウインドウサイズを通達しても構わない のでは、但し、確認応答番号も送っているので、送り側は、どの時点のウインドウサイ ズか、判断出来るはず。 maum> 次にパケットの並び替えです。 maum> これは落ち着いて考えれば何とかなりそうなんですけど、 maum> 要するにルーターを通ったときにその時々でルーティングが変わった場合 maum> 分割されたパケットが順番どおりに届かない可能性があるわけで maum> それをＴＣＰヘッダー内のシーケンス番号順に並べ替えてやる maum> ことですよね。この場合の並べ替え用のバッファサイズって maum> やっぱりウィンドウサイズと同じでいいのでしょうか？ 少なくとも、ウインドウサイズ以上の領域を必要としていると思いますが、連続している 事が確認済みのデータは、どんどん、アプリケーションに渡しても構わない様な気がしま す。 これらを考えると、受信よりむしろ、送信の方が難易度が高そうですね。 ------------------------------------------------------------ )^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^()^o^( ☆☆☆☆☆☆☆☆☆☆☆☆designed by hamayan☆☆☆☆☆☆☆☆☆ from はまやん アドレスは hamayan@xxxxxxxxxxxxxxxx ★★★★★★★★★end of message and thank you★★★★★★★
