UDPを使用した確認応答の信頼性

UDPについて質問があります。コンテキストでは、リアルタイムアクションゲームに取り組んでいます。

私はUDPとTCPの違いについてかなり読みましたが、私はそれらをかなりよく理解していると感じていますが、正しいと感じたことのない作品が1つあります。それは信頼性、特に承認です。UDPはデフォルトでは信頼性を提供しないことを理解しています（つまり、パケットがドロップされたり、順番どおりに到着しないことがあります）。ある程度の信頼性が必要な場合、私が見た解決策（概念的には理にかなっています）は、確認応答を使用することです（つまり、サーバーはクライアントにパケットを送信し、クライアントがそのメッセージを受信すると、確認応答をサーバーに送り返します） 。

確認応答がドロップされるとどうなりますか？

上記の例（1つのサーバーが1つのクライアントにパケットを送信する）では、サーバーはパケットの確認応答が受信されるまでフレームごとにパケットを再送信することにより、潜在的なパケット損失を処理します。それでも帯域幅または順序が乱れたメッセージの問題に遭遇する可能性がありますが、純粋にパケット損失の観点から、サーバーはカバーされます。

ただし、クライアントが到着しない確認応答を送信すると、サーバーは最終的にそのメッセージの送信を停止せざるを得なくなり、そのパケットに含まれる情報が必要な場合、ゲームが中断する可能性があります。サーバーに対して同様のアプローチをとることができます（つまり、ACKに対するACKを受信するまで確認応答を送信し続けますか？）等々）。

ここで私の基本的なロジックは正しいと思うので、2つの選択肢があります。

1. 単一の確認応答パケットを送信し、最善を期待します。
2. 少数の確認応答パケット（おそらく3〜4）を送信し、すべてがドロップされるわけではないと仮定して、最善を期待します。

この問題に対する答えはありますか？基本的に何かを誤解していますか？知らないUDPを使用する保証はありますか？私は自分の論理が健全であると納得するまで、あまりにも多くのネットワークコードを使って前進することをheします。

これは、Two Generals Problemの形式であり、あなたの言うとおりです。再試行の数は、受信を完全に保証するのに十分ではありません。

実際のゲームでは、たとえ技術的に確実に到着したとしても、通常はそれを超える情報は重要ではない期間があります。見つけるのと同じように、2秒前に完璧なヘッドショットが並んでいました。プレーヤーがその情報を使用するには遅すぎます。

パケット損失が非常に大きいため、必要な情報をタイトなリアクションウィンドウ内で定期的に取得できない場合、リアルタイムゲームでは、プレーヤーを蹴って他の場所でより良いマッチを見つけようとするよりも、信頼性の高い接続をエミュレートするためにパケットを送信しようとし続けます。

このため、一部のゲーム複製システムは、確認と再試行を完全にスキップし、できるだけ頻繁に最新の更新をスパムすることを選択します。落としたり遅れたりした場合は、あまりにもひどいので、スキップして次のものを取り上げて、予測と補間システムに頼ってギャップを滑らかにし、プレーヤーに見えるしゃっくりを最小限に抑えます。

私は突然、過去の問題を無視し、現在の瞬間に生きようとすることから、この「シンバレプリケーション」と呼び始めたいと思います。;）

ハイブリッドソリューションは、新しいアップデートの送信に先んじてレースをすることです（ゲームの状態のアップデートは多くの場合非常に小さく/ 圧縮可能であるため）、最後のアップデートもパックインします。おそらくクライアントがそれらを逃した場合に備えて、それを見つけて修正するために完全な往復時間を待つ必要はありません。ほとんどの場合、クライアントはこれをすでに見ているため、この方法で冗長データがありますが、見逃したメッセージを修正するための待ち時間は短くなります。クライアントの更新には、最新の連続更新のインデックス番号を含めることができるため、次の更新パケットに含める古い更新の数を最小限に抑えることができます。

また、2層システムを別のタイプのハイブリッドとして実装することもできます。この場合、短命の状態は信頼性の低いラピッドファイア方式でレプリケートされ、長期の状態はTCPまたは独自の信頼性の実装を使用して高いリトライで確実に同期されますカウント。ただし、2つのメッセージングシステムを維持する必要があり、2つのスナップショットが互いに同期しなくなり、まったく新しいクラスのエッジケースが追加されるため、管理がより複雑になります。

TCPが使用するアプローチは、送信者が確認応答を受信するまでパケットを再送信し続けることです。受信者は重複パケットを無視しますが、それらの確認応答を送信します。送信者は、重複する確認応答を無視します。

パケットが失われると、送信者は既に知っているようにパケットを再送します。
確認応答が失われると、送信者は元のパケットを再送信し、受信者は確認応答を再送信します。

特定の時間内（おそらく60秒、または20回の再試行）に確認が受信されない場合、プレーヤーはゲームから切断されたと見なされます。何らかのタイムアウトルールを実装する必要があります。そうしないと、ネットワークケーブルを外したプレーヤーがサーバー上のリソースを永久に使い果たしてしまいます。

TCPを再発明する場合は、最初にTCPを調べるのが理にかなっています。これは、説明する正確な問題を処理します（解決策の一部は、再試行とタイムアウトにユーザー定義の値を使用することです）。

TCPチャネル（信頼性の高い通信用）とUDP（低遅延通信用）チャネルの2つのチャネルを使用するソリューションは珍しくありません。

一部のソリューションは、クライアントが長すぎる情報を欠落していることを検出し、UDPまたはTCPを使用する再同期を開始します。

別の一般的なアプローチは、確認応答にまったく依存しないようにコミュニケーションを設計することですが、それは質問の範囲外です。

RTSでは、TCPのようなプロトコルを実際に使用することはできません。また、UDPの信頼性を高めることもできません。しようとすると、ネットワークが接続されるたびにゲームがフリーズします。

代わりに、失われたパケットがあまり問題にならないようにプロトコルを設計します。

ショートバージョンは、他のプレイヤーが今どこにいるかを知っている限り、他のプレイヤーが最後のフレームにいたことを気にしないということです。長いバージョンはより複雑です。

質問は次のようになります。パケットが失われたらどうしますか？そして答えは...あなたが推測します。プレイヤーはおそらくまっすぐに動いているでしょう？それらをその線に沿ってさらに1ステップ移動します。...ないRTS選手を除き、これまで直線で移動します。そして、衝突検出があります。

これはきつい。多くのゲームが間違っています。これには正しい答えはなく、トレードオフできるのはさまざまな間違いだけだと主張することができます。

これらのゲームが非常にうまく機能する理由は、これらの問題について長く熱心に考えているだけでなく、インターネットがかなり信頼できるようになったからです。ほとんどすべてのUDPパケットは、実際にタイムリーに宛先に到達します。（ファイアウォールのような永続的な問題がない限り）