私は大学の試験の準備をしていますが、昨年の質問の 1 つは「UDP マルチキャストを信頼性の高いものにする方法」(tcp や失われたパケットの再送信など) でした。
私はこのようなことを考えました：
サーバーは UDP を使用してマルチキャストを送信します
すべてのクライアントは、そのパケットの受信確認を送信します (TCP を使用)
全員がパケットを受信しているわけではないことをサーバーが認識した場合、特定のクライアントにマルチキャストまたはユニキャストを再送信します。
問題は、通常はパケットを失い、サーバーに再送信を強制する 1 つのクライアントが存在する可能性があることです。
いいですか？
すべてのクライアントは、そのパケットの受信確認を送信します (TCP を使用)
パケットごとに ACK を送信し、そのために TCP を使用することは、多数の受信者に拡張できません。NACK ベースのスキームを使用する方が効率的です。
サーバーから送信される各パケットには、シーケンス番号が関連付けられている必要があります。クライアントはそれらを受信すると、どのシーケンス番号が欠落したかを追跡します。パケットが失われた場合、NACK メッセージを UDP 経由でサーバーに送り返すことができます。この NACK は、シーケンス番号のリストまたは受信/未受信のシーケンス番号のビットマップとしてフォーマットできます。
全員がパケットを受信しているわけではないことをサーバーが認識した場合、特定のクライアントにマルチキャストまたはユニキャストを再送信します。
サーバーが NACK を受信すると、欠落しているパケットをすぐに再送信するのではなく、通常は GRTT (グループ ラウンド トリップ時間 - 受信者セットの中で最大のラウンド トリップ時間) の倍数の時間待機する必要があります。これにより、他の受信者からの NACK を蓄積する時間が与えられます。次に、サーバーは不足しているパケットをマルチキャストできるため、不足しているクライアントはそれらを受信できます。
このスキームがストリーミング データではなくファイル転送に使用されている場合、サーバーは代わりにファイル データをパスで送信できます。完全なファイルは最初のパスで送信され、その間に受信した NACK が蓄積され、再送信が必要なパケットがマークされます。その後のパスでは、再送信のみが送信されます。これには、損失率の低いクライアントがファイルの受信を完了する機会があり、損失率の高い受信者が再送信を引き続き受信できるという利点があります。
問題は、通常はパケットを失い、サーバーに再送信を強制する 1 つのクライアントが存在する可能性があることです。
損失が非常に大きいクライアントの場合、サーバーは失われたパケットの最大パーセンテージのしきい値を設定できます。クライアントがそのしきい値を超える NACK を 1 回または複数回 (サーバーによって制限される回数) 送り返すと、サーバーはそのクライアントをドロップし、その NACK を受け入れないか、そのクライアントにメッセージを送信して、その NACK を受け入れなかったことを通知することができます。落とした。
これらの機能を実装するプロトコルは多数あります。
関連する RFC:
UDP の信頼性を高めるには、いくつかのことを処理する必要があります (つまり、自分で実装するなど)。
接続処理:送信プロセスと受信プロセスの間の接続が切断される可能性があります。最も信頼性の高い実装では、通常、keep-Alive メッセージを送信して、両端間の接続を維持します。
順序付け:メッセージは、送信前にチャンクに分割する必要があります。
確認:各メッセージを受信した後、送信プロセスに ACK メッセージを送信する必要があります。これらの ACK メッセージは、UDP を介して送信することもできますが、UDP を介する必要はありません。受信プロセスは、メッセージが失われたことに気付く場合があります。この場合、ホールドバック キュー (受信したメッセージを保持するメッセージのキュー、メッセージの待機室のようなもの) からのメッセージの配信を停止し、不足しているメッセージの再送信を要求します。
フロー制御:データを配信する受信プロセスの能力に基づいて、データの送信を抑制します。
通常、プロセスのグループにはリーダーがいます。これらの各グループには通常、リーダーとグループ全体のビューがあります。これを仮想同期と呼びます。