プロトコルがこれをサポートしていないことは知っていますが、ある程度の信頼性を必要とするクライアントが、破損していることが判明した場合にパケットの再送信を要求する方法をアプリケーションに組み込むことは一般的ですか?
4 に答える
信頼性が必要な場合 (または場合によってはある程度の信頼性のみ)、クライアントが UDP の上に信頼性を実装するのは一般的ですが、TCP が提供する他のもの (厳密な順序どおりの配信など) は必要ありません。時間、低遅延 (またはマルチキャスト、機能する場合)。
一般に、緊急の理由がある場合にのみ、信頼できる UDP を使用する必要があります (たとえば、twitch ゲームなど、非常に低いレイテンシーと高速性が必要な場合)。すべての「通常の」ケースでは、単純に TCP を使用するだけで、同等またはそれ以上のサービスが提供されます。また、TCP よりパフォーマンスが悪い
UDP の上に独自のスタックを実装するのは簡単です。
UDP の上に信頼性 (およびその他の機能) を実装するライブラリの例については、enetを参照してください (Raknet または HawkNL は他の例です)。
もちろん。UDPの上に信頼できるプロトコル(TCPなど)を構築できます。
例
ファイルサーバーを構築していると想像してください。*1024バイトのブロックを使用してファイルを読み取ります*ペイロードを使用してUDPパケットを構築します:ファイル内の「位置」に4バイト、パケットの内容の「長さ」に4バイト。
これで、受信者はUDPパケットを受信します。次のパケットを受け取った場合:* 0-1024:DATA * 1024-2048:DATA * 3072-4096:DATA
パケットが欠落していることを認識し、送信側アプリケーションに2048〜3072の間にパーツを再送信するように要求します。
これは、アプリケーションコードがパケットの構築とペイロードの解釈を処理する必要があることを説明するための非常に基本的な例です。使用しないでください。エッジケース(最後のパケット、破損したパケットのチェックサムなど)は考慮されません。
信頼できる UDP が必要な場合、何を使用しますか?という質問への回答を参照してください。