返信

>tracerouteは、ＭＳ－ＤＯＳで使うtracertと同一の機能を
>持っているものだと思いますが、

そうですが，両方試す必要はありません。
PingPlotterの方がわかりやすいですから，それだけで十分です。

>受信したＵＤＰパケットの情報を元に音声の再生、ディスプレイへの表示を
>行っています。

音声や映像データをUDPで流すアプリケーションは要注意です。
UDPで音声を流すものは，受信確認を行わないことが多いのですが，
受信確認を行わないと，相手の状態や途中の混雑状態を判断できないので，
途中で混雑していてもお構いなしにパケットを垂れ流すことになります。
そのため，トラフィックが増えたときに，
ルータやスイッチの待ち行列を溢れさせる原因になりやすいからです。
音声パケットの遅延を抑制するためにルータで待ち行列を分けて
音声パケットを優先的に流すことがありますが，それはもっと要注意です。
音声パケットを優先するため，他のアプリケーションにしわ寄せがいき，
そちらのパケットが消えることになるからです。

UDPパケットが消えているのなら，
TCPのパケットも消えている可能性が高いですね。

>監視、制御などは、ＴＣＰで行っています。
>具体的な名前などは、セキュリティ上の問題などから
>個人的に電子メールでやりとりを希望したいです。

いえ，pushフラグは，現時点では重要ではないので，
そこまでは必要ありません。

>ＴＣＰでフロー制御する際に、受信側のウィンドウサイズを送信側に通知し
>そのサイズに合わせて、送信側が一度に送れるサイズを調整すると

えーと，どう説明したらいいのでしょうか。
データを送信する方は相手から通知されたウインドウサイズを超える量の
データを送らないようにします。
つまり，通知されたウインドウサイズ分だけデータを送信したら，
受信確認が返ってくるまで送信動作を一時休止する，ということです。
これが，書籍に書いてあったことの意味です。
しかし，その動きと，データ送信時にヘッダにセットするウインドウサイズの値は，
まったく関係がありません。
TCPは全二重で送受信しますから，
送信と受信が同時に実行されることを想定しています。
データ送信時にヘッダにセットするウインドウサイズの値は，
送信側のマシンが受信動作を行うときのことを考えて，
受信バッファの空き領域を相手に知らせているわけです。