2

UDP パケット (512 バイト) を介してプレイヤー情報をリモート サーバーに送信するゲーム用のプラグインを Lua でプログラムしました。リモート サーバーは、パケットからデータを読み取り、すべてのプレイヤー情報を xml ファイルに集約します (このファイルは、お互いの現在の状態を確認できるように、すべてのプレイヤーが Web を使用します)。

着信パケットを処理するために DatagramSocket を使用して Java でサーバーをプログラミングしましたが、奇妙な動作に気付きました。一定の時間が経過すると、DatagramSocket は約 10 ～ 12 秒間、一時的に接続の受け入れを停止したように見えますが、その後、通常の動作を再開します (私が見ることができる例外はスローされません)。クライアントがパケットを送信する頻度と、この動作が発生する速度との間には、確実に関係があります。クライアントの更新頻度を上げると、DatagramSocket はより早く「失敗」します。

言及する価値があるかもしれませんが、受信した各パケットは、パケット内のデータを処理するスレッドを生成します。違いがあれば、Linuxでサーバーを実行しています！

この種の動作が発生する原因を知っている人はいますか?

アンドリュー

4

3 に答える 3

3

UDP は、配信の保証がまったくないネットワーク プロトコルです。途中の任意のネットワーク コンポーネント (クライアントおよびサーバー PC 自体を含む) は、高負荷やネットワークの輻輳など、何らかの理由でパケットをドロップすることを決定できます。

これは、パケット損失が発生している場所を見つけるために、少し詳しく調べる必要があることを意味します。Wireshark などを使用して、パケットがサーバーに到着しているかどうかを確認できます。

低遅延よりも信頼性の高い配信が重要な場合は、TCP に切り替えます。UDP に固執する場合は、この特定の時点でこの特定の問題を修正するかどうかに関係なく、パケットが失われることを考慮する必要があります。

于 2011-11-29T16:28:26.587 に答える
3

私の推測では、サーバー側の受信バッファ スペースが不足していると思われます。

設計を再検討することをお勧めします。スレッドの生成はかなりコストのかかる操作です。着信パケットごとにこれを行うと、システムのスループットが比較的低くなり、受信キューが増大する理由を簡単に説明できます。

また、Linux での実行時の UDP 受信バッファー サイズの指定も参照してください。

PS UDP ではメッセージの配信が保証されないことは既にご存じのことと思いますので、その点については触れません。

于 2011-11-29T16:29:17.087 に答える
1

UDP パケットごとにスレッドを開始することは、悪い考えTMです。UDP サーバーは、伝統的に単純な受信ループとしてコーディングされています (結局のところ、必要なソケットは 1 つだけです)。このようにして、スレッド、同期などのすべてのオーバーヘッドを回避できます。

于 2011-11-29T16:30:50.040 に答える