私は今後数日でudpを学んでいます。今週末、私はそれらの 72 時間の競争の 1 つに参加する予定で、その UDP コードをオンラインで動作させたいと考えています。大会中はインターネットがありません（誰かに電話してテストしてもらうことはありません）。
パケットが 2 回受信される、複数のフレームが受信されない (ただし、予想されるミリ秒の長さはわかりません)、推奨されるバイト サイズ (576) など、UDP に関するいくつかの問題を知っています。 UDPプログラミングについて？
しかし、LAN からインターネットに移行した後、どのようなことが起こりますか?
注: できるだけ早くいくつかのコードを実行し、オンラインでテストします。私の最終コードがどのように見えるかを願っていますが、いくつか見逃す可能性もあります。
簡単な答えは次のとおりです。LAN では、UDP のトレードオフ (良い点と悪い点) がほとんどないことに気付くでしょう。LAN ではうまくいかないことがほとんどないからです。
パケットが失われる可能性があります。LAN の輻輳またはローカル システムの制限が原因である可能性が最も高いです。
LAN を離れてルーターに依存すると、UDP の問題の大部分が発生します (断片化、パケットの重複、パケットの遅延、特定のサイズを超えるパケットの破棄、返されるエラー メッセージの欠如)。
つまり、UDP を複雑にしているのは、ほとんどが「LAN を離れる」ことです。
遅延が増加し、パケット損失が増える可能性があります。これは、送信機と受信機がどこにあるかによって異なります。米国にいて、オーストラリアと UDP で通信しようとしている場合、遅延がかなり大きくなり、移動距離が長くなり、パケットのパスが増えるため、パケット損失/再注文パケット/重複が多くなります。ルーティングされます。
UDP をトランスポート プロトコルとして使用している場合は、アプリケーション プロトコル内で伝送を保護する必要があります。これを行うにはいくつかの方法があります。
これらをアプリケーション パケットのヘッダーとして送信し、受信側でチェックする必要があります。
PS: プロトコルのすべての側面 (一部だけでなく) で正しいパケット順序と完全性に本当に依存している場合は、TCP に切り替える必要があります。
これは少し極端かもしれませんが (!)、これが重要な場合は、着信データグラムをリッスンして転送する UDP プロキシを作成できます。これを変更して、以下を提供できます。
クライアントにデータをプロキシに送信するように指示し、プロキシに（適切なパケット変更を加えて）サーバーに送信するように指示します。
私が言うように、おそらく極端です。ただし、LAN/インターネットが存在する場合でも、これを使用して、UDP に適していない環境でのアプリケーションの動作をテストできます。
編集:確かに誰かがこのようなものを書いていますか? そうでない場合は、オープンソース プロジェクトが進行中のように感じます....