タグ付けされた質問 「udp」

UDPは、通常、データ使用量の多いリアルタイムマルチプレイヤーゲームに推奨されることを知っています。 ほとんどの記事は数年前に作成されたものであり、インターネット上で送信されるすべてのデータの〜80％がTCPであるため、TCPに対して多くの最適化が行われたに違いありません。 これは私に不思議にさせます：UDPはまだ速度と待ち時間の点で優れていますか？最近のTCP最適化により、TCPはUDPよりもパフォーマンスが向上しましたか？

71 c++  networking  udp  realtime 

UDPについて質問があります。コンテキストでは、リアルタイムアクションゲームに取り組んでいます。 私はUDPとTCPの違いについてかなり読みましたが、私はそれらをかなりよく理解していると感じていますが、正しいと感じたことのない作品が1つあります。それは信頼性、特に承認です。UDPはデフォルトでは信頼性を提供しないことを理解しています（つまり、パケットがドロップされたり、順番どおりに到着しないことがあります）。ある程度の信頼性が必要な場合、私が見た解決策（概念的には理にかなっています）は、確認応答を使用することです（つまり、サーバーはクライアントにパケットを送信し、クライアントがそのメッセージを受信すると、確認応答をサーバーに送り返します） 。 確認応答がドロップされるとどうなりますか？ 上記の例（1つのサーバーが1つのクライアントにパケットを送信する）では、サーバーはパケットの確認応答が受信されるまでフレームごとにパケットを再送信することにより、潜在的なパケット損失を処理します。それでも帯域幅または順序が乱れたメッセージの問題に遭遇する可能性がありますが、純粋にパケット損失の観点から、サーバーはカバーされます。 ただし、クライアントが到着しない確認応答を送信すると、サーバーは最終的にそのメッセージの送信を停止せざるを得なくなり、そのパケットに含まれる情報が必要な場合、ゲームが中断する可能性があります。サーバーに対して同様のアプローチをとることができます（つまり、ACKに対するACKを受信するまで確認応答を送信し続けますか？）等々）。 ここで私の基本的なロジックは正しいと思うので、2つの選択肢があります。 単一の確認応答パケットを送信し、最善を期待します。 少数の確認応答パケット（おそらく3〜4）を送信し、すべてがドロップされるわけではないと仮定して、最善を期待します。 この問題に対する答えはありますか？基本的に何かを誤解していますか？知らないUDPを使用する保証はありますか？私は自分の論理が健全であると納得するまで、あまりにも多くのネットワークコードを使って前進することをheします。

16 networking  udp 

読んだ後であるUDPをまだ良いTCPよりもデータが重いリアルタイムゲームのため？、TCPとUDPの両方を同時に使用するのは理にかなっているのでしょうか。 まれに送信されるが、確実に到着することが保証されている情報を送信するためのTCP。 スコアの更新、プレーヤーの名前、ゲームの世界でのライトのオン/オフの状態など。 絶えず更新され、時々失われる可能性がある情報を送信するためのUDP。新しい情報が常に送信されるためです。 位置、回転など これは理にかなっていますか？考えられる欠点は何ですか？ これを処理するより良い方法はありますか？

10 networking  multiplayer  udp 

マルチプレイヤーゲーム（64歳未満のプレイヤー向け）を作成しています。私はすでにネットワークループ用に別のスレッドを用意することを決めましたが、UDPを受信するための追加のスレッドを作成するのか、受信用ソケットを非ブロッキングに設定する（追加のスレッドなしで）のが良いのか疑問に思っていました。 または、非同期ソケットのような別の方法を使用する方が良いですか？より良い方法はいつでも歓迎です！

10 networking  multiplayer  multithreading  udp 

私はネットワーク化されたiOSゲームを書いています。でパケットを送信するときGKMatchSendDataReliable（私はどの仮定 60のパケット毎秒（隣接パケット間のように16ミリ秒）、平均ping時間でUDPを書き込む自分のパケット受信コードであった）急速に悪化：私は次々 （以下7個のゲームセンターの一致を開い）、100パケットの「フラッド」を送信しました（毎秒60パケットのレートで）。私は平均往復時間を測定しました、そしてこれらは結果です： [ 21:16:39 ]: I saw an average roundtrip time of 52.342787 ms, he saw 54.496590 ms [ 21:16:34 ]: I saw an average roundtrip time of 62.631942 ms, he saw 61.991655 ms [ 21:16:45 ]: I saw an average roundtrip time of 88.394380 ms, he saw 83.619123 …

9 networking  udp 

現在私のゲームでは、クライアントはレンダラーにすぎません。入力状態が変更されると、クライアントはサーバーにパケットを送信し、プレーヤーが入力を処理しているかのようにプレーヤーを移動しますが、サーバーは最終的な判断を下します。 これは、1つの大きな問題を除いて、通常は非常にうまく機能します。基本的に、プレーヤーが崖に向かってエッジに向かって歩いていて、エッジから出る直前に停止する場合、場合によっては1秒後に、エッジからテレポートされます。これは、サーバーが情報を処理した後で、「Wを押すのをやめた」パケットが送信されるためです。 ここに私が何を意味するかを理解するのに役立つラグダイアグラムがあります：http : //i.imgur.com/Prr8K.png サーバーが処理するフレームごとに "W Pressed"パケットを送信するだけでもかまいませんが、これは帯域幅のコストがかかるソリューションのようです。 どんな助けでもありがたいです！

9 xna  c#  networking  interpolation  udp 

クライアントがIPアドレスを偽装し、他のクライアントをだましてサーバーにだましていることを考えています。そのようなもの。（私はこれについてあまり知らないので、これが完全に間違っている場合は、私を修正してください。） これを防ぐにはどうすればよいですか？リアルタイムゲームなので、暗号化を使用する場合は、RC4のような高速で安全なものを使用します。サーバーがクライアントに提供するキーでパケットデータを暗号化する必要がありますか？ 違いがある場合は、UDPを使用しています。

9 networking  security  udp  authentication 

私たちはリアルタイムのマルチプレイヤーゲームを構築しています。このゲームでは、各プレイヤーがゲームループの反復ごとにその状態を報告する責任があります。 状態の更新は、信頼できないUDPを使用してブロードキャストされます。 状態データの送信を最小限に抑えるために、デルタ（変更された状態データに関係なく）のみを送信するシステムを考え出しました。 ただし、パケットが失われると他のプレイヤーがデルタを受信できなくなり、ゲームが予期しない動作をするようになるため、この方法には欠陥があります。 例えば： 状態は次の要素で構成されていると想定します：{positionX、positionY、health} Frame 1 - positionX changed --> send a packet with positionX only. Frame 2 - health changed // lost ! Frame 3 - positionY changed --> send a packet with positionY only. //他のプレイヤーは健康状態の変化について知らない。 では、どうすればこの問題を克服できるでしょうか？データ全体を送信することは常に可能であるとは限りません。

8 networking  multiplayer  state  udp