9

多くのゲーム開発者は、アプリケーション レベルでUDPの 信頼性を高めることを選択しています。それがTCPの目的ではありませんか？UDP および TCP パケットを使用してクライアント サーバー通信を可能にする API を作成しました。信頼できる UDP をリストに追加する必要がありますか? なぜ？TCP を使用しても問題はありますか?

RUDP サポートを追加するかどうかを選択できるように、RUDPが TCP よりも優れているかどうかを知りたいだけです。

4

4 に答える 4

12

簡単な答え: TCP はレイテンシに対して (まったく) 最適化されていません。その結果、ゲームのレイテンシ キラーであるいくつかのプロパティがあります (ただし、パケットが失われた場合にのみ機能します)。特に、ヘッド オブ ライン ブロッキングと指数関数的バックオフは、ペースの速いゲームでは非常に煩わしい傾向があります。

レイテンシーを最も悪化させるのは、ヘッドオブライン ブロッキング (別名 HOL ブロッキング) です。1 つのパケットが失われると、同じストリーム内の後続のすべてのパケットは、たとえ通信の反対側に到達したとしても、到達できなくなります。失われたパケットが再送信されるまで、アプリ レベル (痛い!) (これには約 2*RTT かかります。大陸ごとのサーバーの場合でも、約 100 ミリ秒です (=シューターでは、すでに殺されています) )))。

長い答え:

これは複雑な問題であり、いくつかの異なるシナリオを区別する必要があります。

  1. 信頼できる順序付けられたメッセージ (またはバイト) ストリームが必要です。この場合、TCP に対する RUDP の利点は存在しますが、ごくわずかです (再送信時間を短縮して、指数バックオフをなくすこともできますが、それだけです)。特に、あらゆる種類の信頼できる順序付けられたストリーム (TCP、RUDP、またはその他のもの) では、行頭ブロッキングは依然として避けられません。

  2. 信頼できるが潜在的に順序付けされていないメッセージ配信が必要です。これにより、HOL ブロッキングを回避できる場合がありますが、かなり複雑なアプリ レベルの処理が必要になります。

  3. 信頼性はまったく必要ありません (="ファイア アンド フォーゲット")。そのような情報の典型的な例の 1 つは、弾丸のヒットを表示する必要がある場合です。すぐに表示しなかった場合、0.5 秒後に表示する必要はありません。無視して、パケットの再送信にリソースを費やさない方がよいでしょう。

  4. 最終的に同期された状態が必要です（ただし、すべての中間状態を通過することは気にしません）。これは、シミュレーションの非常に一般的なシナリオです。これは、UDP を介して実装することが可能です (HOL ブロッキング ペナルティを被ることなく)。ただし、信頼性の低い接続で圧縮を有効にすることは簡単ではなく、圧縮はほとんどのゲームで必須です。幸いなことに、このような圧縮は実行可能です ( http://gafferongames.com/networked-physics/snapshot-compression/および/またはhttp://ithare.com/udp-from-mog-perspective/#low-latency-compressionを参照)。議論のために）。このアプローチが実装された場合 (完全に信頼性の低いパケットの上で実行できます)、TCP よりも大幅に改善されます (HOL ブロッキングが排除されるため、ネットワーク ティックの順序の遅延について話しているのですが、これは可能です)。 1/120sec~=8ms という低さ - RTT 前後の遅延で、これらは 1 つのパケットが失われた場合に少なくとも 100ms です)。

サイドコメント:

実際、UDP over TCP をシミュレートすることは可能です (TCP レイテンシーを排除します) - http://ithare.com/almost-zero-additional-latency-udp-over-tcp/を参照してください。ただし、それを利用するには、上記のすべてを手動で行う必要があることに注意してください。信頼性の高い順序付けされたストリームの HOL ブロッキングを回避できる特効薬はまだありません。代わりに、この手法を使用すると、複数の TCP 接続を確立して、信頼性は低いがブロックしない UDP であるかのように動作させることができます。

于 2017-05-26T07:14:42.983 に答える