多くのテーブルをホストするポーカー ゲーム サーバーを考えてみましょう。プレーヤーがロビーにいる間、すべてのアクティブなテーブルとその統計のリストがあります。これらの統計は、プレイヤーがテーブルに参加、プレイ、退出するたびに常に変化します。テーブルを追加して閉じることができます。何らかの方法で、これらの変更をクライアントに通知する必要があります。
この機能をどのように実装しますか? ロビーに TCP/UDP を使用しますか (つまり、ユーザーがロビーを監視するためにサーバーに接続する必要がありますか、それとも要求応答メカニズムを使用しますか)? サーバーは各イベントについてクライアントに通知しますか、それともクライアントはサーバーをポーリングする必要がありますか?
心に留めておいてください: おそらく、そのようなシステムの最も重要な目標はスケーラビリティです。すべてのユーザーが複数のサーバーから構成される 1 つの大きなリストを表示する必要がある一方で、増加する視聴者に対処するためにサーバーを追加するのは簡単である必要があります。
この特定の問題は、アプリケーション設計における非常に基本的な問題 (クライアントがサーバーに接続する方法) の現れです。
スケーラビリティが問題になる場合は、 Reactor 設計パターンなどのノンブロッキング I/O パターンを使用して、常にスケーラブルなソリューションに頼ってください。そのようなパターンの動作およびテスト済みの実装が既にある標準的なソリューションを使用することをお勧めします。
具体的には、常に更新される高速動作のゲームを含むあなたの場合、TCP 経由で各クライアントへの接続を保持し、クライアントを更新するスケーラブルなサーバー (ここでも、ノンブロッキング I/O) を使用するのが妥当に思えます。彼が知る必要がある情報。
リクエストとレスポンスのサイクルはあなたのケースにはあまり適していないように思えますが、これはアプリケーションの正確な仕様に対して検証する必要があります。
それが私の基本的な提案です：
サーバーは、リストに適用された固定長の操作のキューを保持するインターフェイスを介して、リストを更新します (追加、削除、および既存の項目の変更)。各操作にはタイムスタンプが与えられます。キューがいっぱいになると、最も古い操作が徐々に破棄されます。
ユーザーが最初にリストを取得する必要がある場合、完全なリストを送信するようにサーバーに要求します。サーバーは、現在のタイムスタンプを含むリストを送信します。
任意の期間 (10 ～ 30 秒?) ごとに、クライアントはサーバーに、取得したタイムスタンプ以降にリストに適用されたすべての操作を送信するように要求します。次に、サーバーはタイムスタンプがまだリストに表示されているかどうか (つまり、最初のアイテムのタイムスタンプよりも大きいかどうか) を確認し、表示されている場合は、その時点から現在までに発生した操作のリストと、現在のタイムスタンプ。古すぎる場合、サーバーは完全なリストを再度送信します。
たまに「更新サイクル」が失われても大したことはないので、UDP はこのアプローチに適しているようです。