5

毎秒最大 3000 個の UDP パケットを受信して​​います。それぞれのサイズは最大 200 バイトです。これらのUDPパケットをリッスンし、データをファイルに書き込むだけのJavaアプリケーションを作成しました。次に、サーバーは以前に指定されたレートで 15000 メッセージを送信します。ファイルに書き込んだ後、約 3500 件のメッセージしか含まれていません。Wireshark を使用して、15000 件すべてのメッセージがネットワーク インターフェイスで受信されたことを確認しました。その後、ソケットのバッファ サイズを変更してみました (最初は 8496 バイトでした)。

(java.net.MulticastSocket)socket.setReceiveBufferSize(32*1024);

この変更により、保存されるメッセージの数が最大 8000 に増加しました。バッファサイズを1MBまで増やし続けました。その後、保存されたメッセージの数は ~14400 に達しました。バッファ サイズをより大きな値に増やしても、保存されるメッセージの数は増えません。許容される最大バッファ サイズに達したようです。それでも、ネットワーク インターフェイスが受信した 15000 件のメッセージをすべてキャプチャする必要があります。

どんな助けでも大歓迎です。前もって感謝します。

4

5 に答える 5

5

おそらくあなたのコードにバグのような匂いがします。UDP パケットがネットワーク経由で配信される場合、Wireshark で見たように、配信のためにローカルでキューに入れられます。おそらく、あなたのプログラムはソケットからの読み取りをタイムリーに進めていないのでしょう。このタスク専用のスレッドはありますか?

プログラムによって失われているパケットを検出することで、ある程度の前進ができる場合があります。失われたすべてのパケットが初期のパケットである場合、プログラムが受信を待機する前にデータが送信されている可能性があります。それらがすべて遅い場合は、終了が早すぎる可能性があります。それらが一定の間隔である場合、パケットの受信をループするコードに問題がある可能性があります。等

いずれにせよ、あなたはパケットが失われることを非常に心配しているようです。設計上、UDP は信頼できるトランスポートではありません。これらのマルチキャスト パケットの損失が (パフォーマンス上の理由で解決したい謎ではなく) システムの問題である場合は、システム設計が間違っています。

于 2011-11-25T10:08:47.453 に答える
1

UDP を使用してファイルの内容を送信しているようです。UDP では、パケットの順序は保証されません。順序を気にしない場合は、すべてのパケットをキューに入れ、別のスレッドでキューを処理し、内容をファイルに書き込みます。これにより、ファイル操作が原因でソケット リーダー スレッドがブロックされることはありません。

于 2011-11-25T10:18:56.867 に答える
1

あなたが抱えていると思われる問題は、ファイルへの書き込みが遅れることです。ファイルに書き込む (または別のスレッドでファイルに書き込む) 前に、すべてのデータをメモリに読み込みます。

ただし、パケットの再送信を要求する機能がなければ、UDP でパケットの 100% を確実に受信する方法はありません (TCP が代わりに行います)。

于 2011-11-25T10:09:31.947 に答える