ｍａｕｍです。
> "n.kobayashi"> IPまでは動くのですが,TCPの状態遷移でFreezeしてしまいます
> "n.kobayashi"> μITRONにまだBUGがあるような気がしています
>
> なかなかＩＴＲＯＮ関係の、優れたドキュメント、印刷物って無いですが、
> 私が思うに、実装で困ったら、最高のドキュメントが有ると思います。
> TOPPERSのソースコードです。
> 先日、ＥＴ２００２のテクニカルセッションで、ＩＴＲＯＮの入門用セッション、
> 正に入門レベルの私向け！に行ってきましたが、高田先生も、なるべくカーネル
> ソースを読んでくれ！と言っていました。是非有効活用しちゃいましょう。
ＴＲＯＮは関数の仕様しか記述していないのですよね。
ですから、実装は各設計者にお任せという状態になっています。
ということくらいしか知りません。すいません
>
> ＴＣＰ／ＩＰのプロトコルの実装で、情報交換等できましたら、と思っています。
> 宜しくお願いします。
>
> ｍａｕｍさんも読んでますかー！
読んでます、読んでます。ちょっと今考えていることをざっくり書いて見ますね
長文ですいません。
ＴＣＰ／ＩＰの実装で問題なのは今のところ２点あります。
１つは以前にhamayanさんがおっしゃっていたウィンドウ制御、
それとパケットの並べ替えです。
どちらもサーバー、クライアントが通信状態になってからの
制御になると思います。
以下、私の頭の中にある考え方を記述しますので間違えていたら指摘してください。
ＲＦＣを読破しているわけじゃないです。
んじゃ、まずウィンドウ制御から話題にして・・・
ＴＣＰはスライディングウィンドウですから、送り先は勝手にパケットを
いくつか送れますよね。（ＴＣＰはコネクションを張る前にセグメントの
ネゴシエーションをして１パケットがセグメントを越えて転送されることはない。
普通は0x5b4(1460)に設定されることが多いようです。）
で、たとえば受信バッファに4KB割り当てたとするとウィンドウサイズは
0x1000になりますよね。そこまではいいのですけど
相手からのパケットが来て、自分がackパケットを送信しようとしている最中に
さらに相手からパケットが来てしまったということが発生しうるわけで
そうした場合、相手に対して自分のウィンドウサイズを通達するタイミングを
逃してしまうじゃないですか？
それとも、送信側は相手（受信側）のウィンドウサイズを知っているわけで
すから、その範囲内でパケットを連続して送ってくるのですかね？
次にパケットの並び替えです。
これは落ち着いて考えれば何とかなりそうなんですけど、
要するにルーターを通ったときにその時々でルーティングが変わった場合
分割されたパケットが順番どおりに届かない可能性があるわけで
それをＴＣＰヘッダー内のシーケンス番号順に並べ替えてやる
ことですよね。この場合の並べ替え用のバッファサイズって
やっぱりウィンドウサイズと同じでいいのでしょうか？
運良くパケットが全部そろえばいいですけど、ロストする可能性だって
あるわけで、一体何秒待つのが妥当な数字なの？
とか、実装するには課題が一杯あるんで乗り上げてます。
==============================================================
植木 誠 <maum@xxxxxxxxx>
==============================================================
