返信

>小山さん，こんにちわ。
>今年は台風が多いですね。

早いお返事ありがとうございます、小山です。
今回の台風の影響は、強烈なものではなかったみたいですね...。

>さて，TCPコネクションの件ですが，
>どこかがおかしいんでしょうねぇ．．．

スニファーを使って調べてみましたが、
ＴＣＰ層において
ウィンドウ凍結、トランスポート再送、Ａｃｋ時間超過、誤転送フレーム
応答なし等が発生していました。
この中でも特に、ウィンドウ凍結、トランスポート再送、応答なしが
目立っています。
これらが発生する原因として、受信バッファ不足やネットワーク輻輳などが
考えられますが、何が引き金になって、このような状況に陥ったか
読み取ることができません...今のところは...。
確かに、伝送速度が１００Ｍや１０Ｍで行っているところから
１２８Ｋの回線にデータを送っているから、レスポンスが悪くなって
いるのかと考えましたが、流れるデータの最大量は６４Ｋ前後なので
途中で回線が細くなったからと言って、回線容量以下のデータが欠けるとは
考えにくいと思います。いかがでしょうか？

>ありがちな原因を考えてみると，
>IPアドレスを重複して割り当てているとか，
>何らかのエラーでIPパケットが途中で落ちるとか，
>TCPプロトコルソフトに何らかの異常があるとか，
>といったことでしょうけれど，この中に思い当たるものはありますか？

先ほどと重複しますが、何らかの原因（原因不明）でＴＣＰの再送が多くなり、
ネットワーク負荷が増大し、ＵＤＰが破棄されている可能性があるようですが
パケット破棄されているかどうか、スニファーでは読み取れません...。
アプリケーションでみると、ＵＤＰ受信したデータが表示されるので
パケットが来なければ表示されないので、目視で判断しています。

>この手のトラブルはパケットを採取して調べてみるのが，
>一番手っ取り早いように思いますが，
>パケット採取はできますか？

ＴＣＰパケットの中で、ＰＳＨフラグがあり、規則的に１がある時が
見受けられましたが、このタイミングはＴＣＰの規則か何かで決められて
いるのでしょうか？

あと、ウィンドウサイズを受信側から送信側へ通知していますが、
そのままのウィンドウサイズが反映されず、なぜか通知されたウィンドウサイズ
から、１７５バイトを引いた値が送信のウィンドウサイズになっていました。
例えば、受信側から通知されたウィンドウサイズが８７２５バイトだった場合は
送信側のウィンドウサイズは、８５５０バイトでした。
このウィンドウサイズの動作はこれで合っているのでしょうか？

分かる範囲で教えていただければ幸いです。
よろしくお願い致します。