私は現在、マルチプロセスネットワークゲームサーバー（1つのゲートキーパープロセスを作成しています。これは、現在どのゲームが実行されているかをプレイヤーに伝え、ゲームを作成して参加させるものです。どの場合、TCP接続を終了する必要がありますか？
ゲートキーパーがクライアントにTCP接続をドロップすると便利な場合は、リスニングを続ける必要がありますか？例えば。クライアントが正常にゲームに参加した後、またはゲームのリストを取得した後、またはエラーが発生したとき（ゲームに参加しようとしている空きスロットがないなど）に、ゲートキーパーが接続を閉じる必要があります。または、接続がタイムアウトして閉じる必要がありますか？ありがとう。
最も簡単なプロトコルでは、各トランザクションごとに個別の接続を使用することがよくあります。最も簡単な操作モードでは、Webブラウザは接続してページをダウンロードしてから切断します。ただし、同じサーバーに繰り返し接続したり切断したりするとオーバーヘッドが発生するため、reuse an existing connectionも可能です。
一方、接続の使用の間に長い遅延があり、多数のクライアントがある場合は、サーバーが管理できる同時接続の制限された数を考慮する必要があります。これは、非アクティブなタイムアウトが有用な場合があります。
接続を開いたままにすると、クライアントがファイアウォールの外側にいる必要もなく、サーバー間で非同期通知を行うことができます。クライアントは接続を確立して保持し、常に接続を保持します。サーバーは、接続を介して通知を送信します。
プロトコルを設計するのが最も簡単な方法です。これはおそらく、トランザクションの終了時に接続を閉じることを意味します。
アプリケーション（オンラインゲームのゲートキーパー）のパフォーマンスが重要でない場合や、クライアントが拡張会話を行う必要がない場合は、トランザクションの最後にソケットを閉じる必要があります。
クライアントは、別の質問をする必要がある場合は、後でもう一度することができます。
負荷が非常に大きい場合（サーバーあたり10kの同時セッションと考える）、サーバーで多数のクライアントをサーバーに1つ（または少数の）ソケットを使用できるUDPの使用を検討してください。
私はリビングのためのネットワークゲームで働いています。ウェブやXMLリクエストではない私たちの接続はすべて、関連性がある限りオープンしています。クライアントはサーバーへの接続を開き、次のいずれかが発生するまで開いたままにします。
を殺す（該当する場合、エラー メッセージで） 切断パケットを送信し、その後 によってこれを行います。 UDPは今日使用されているさまざまなファイアウォールの設定に苦労しています。あなたが何か漠然としていることをしているのであれば、UDPの上にパケット保証システムを書く必要があります。 。旧バージョンのエンジンから新しいエンジンへとUDPからTCPに切り替えました。
ありがとう、あなたはとても役に立ちました。 – dpq
だから、タイムアウトやユーザーがゲームに参加したり自発的に接続を閉じるときにのみ、接続を閉じて、利用可能なゲームのステータスを更新しておくようにしてください。ありがとう。 – dpq