返信

>>ウィンドウ凍結、トランスポート再送、Ａｃｋ時間超過、誤転送フレーム
>>応答なし等が発生していました。
>これは，要するに，受信確認応答パケットが受信側から返って来ていない，
>ということでしょうか？

大半は、戸根さんの言われるとおりで間違いないと思います。

>tracerouteとかPingPlotterっていうユーティリティは知っていますか？
>（PingPlotterはhttp://www.pingplotter.com/で入手可能）
>これを使うと，どこかでパケットが落ちいないかどうか検査できます。
>（精度はそんなに高くないですけど）
>試してみるといいかもしれません。

tracerouteは、ＭＳ－ＤＯＳで使うtracertと同一の機能を
持っているものだと思いますが、
tracerouteというプログラム（ツール）が、インターネット上に落ちている
という意味ですか？
PingPlotterの方は早速、試してみます。

>通信回線に流れ込んでいくデータが64Kbps程度であれば，
>それほど問題は起こらないはずなんですが，
>通信回線側にパケットを送っている機器が他にあれば話は別です。
>その辺，見落としはないでしょうか？

もう一度、見直してみます。

>Pushフラグはアプリケーション側でコントロールするものなので，
>アプリケーションがそうしている，というだけです。
>アプリケーションはどういったものですか？

受信したＵＤＰパケットの情報を元に音声の再生、ディスプレイへの表示を
行っています。
監視、制御などは、ＴＣＰで行っています。
具体的な名前などは、セキュリティ上の問題などから
個人的に電子メールでやりとりを希望したいです。
いかがでしょうか？

>ウインドウサイズっていうのは，要するに，
>自分の受信バッファの空き領域のサイズを相手に知らせるもので，
>相手側から通知してきた値とは関係ないですから，気にする必要はありません。

ＴＣＰでフロー制御する際に、受信側のウィンドウサイズを送信側に通知し
そのサイズに合わせて、送信側が一度に送れるサイズを調整すると
ある書籍に書いてあったので、その説明と相違する現象が今回のパケット解析で
現れていたので．．．。解析の仕方がまずかったのかな？
それでは、また．．．。