サーバーに大量のデータを送信すると、受信バッファ サイズが小さいために受信パケットの一部が失われます。
あなたはそれを知りません。多くの原因が考えられます。
今、私はそのような方法で受信バッファを設定しています -
DatagramChannel serverChannel;
serverChannel.setOption(StandardSocketOptions.SO_RCVBUF, 1024*1024*10); // 10 MB
それは理にかなっていますか？
実際には、これは膨大なバッファーであり、オペレーティング システムはそれをより適切なサイズに切り詰める場合があります。設定後にオプションを取得してみて、実際のサイズを確認してください。
このコードは、パケット損失の問題を解決しませんでした。
誰もそうするとは言わなかった。あなたはそれを仮定しただけです。
もう 1 つ質問があります。私のネットワーク コントローラの受信バッファ プロパティはデフォルトで 512 です。これはバイト単位ですか、それともメガバイト単位ですか。
使用している NIC を教えていただくまで誰も答えられませんが、製造元のデータからご自身で確認できるはずです。
512 バイトの場合、このプロパティを手動で増やす必要がありますか?
不必要なだけでなく、不可能です。
プログラムでバッファーを増やすと、実際にはオペレーティングシステムのバッファーが増加すると思います
ソケットの受信バッファ サイズを制御するという意味であればSO_RCVBUF、それは正しいです。
しかし、これは意味がありません
はい、そうです。
最初にudpパケットがネットワークカードに「来る」ためです。
そしてそこからオペレーティング システムへ、そこから IP スタックへ、そしてそこから UDP スタックへ、そしてそこからソケット受信バッファへ。ほとんどのパス MTU が最大 1500 バイトである場合、NIC が 512 バイトのバッファーを持つ可能性は低いようですが、たとえば 512k であることは理にかなっています。結局のところ、それで十分だと考えることができます。
あなたの基本的な仮定には欠陥があります。UDP パケットは、さまざまな理由で失われる可能性があります。送信されなかった、中間ルーターによってドロップされた、フラグメント化され、一部のフラグメントがレシーバーに届かなかった、またはレシーバーのソケット受信バッファーがいっぱいになったために、小さすぎるか、受信者が送信者に追いつけないことが原因である可能性があります。巨大なソケット レシーバー バッファーを使用するだけでは、これらの問題の 1 つにしか対処できません。信頼性が必要な場合は、TCP を使用するか、再試行を伴う ACK または NACK メカニズムを実装してください。