私はリアルタイムゲーム用のTCPソケットサーバーを設計しており、そのアーキテクチャには2つのアプローチがあります。はい、どうぞ：
2つのスレッドを開始します。無期限のループで新しい接続をリッスンし、アレイに新しいクライアントを追加します。次に、アレイからすべてのクライアントソケットを順番にスキャンし、それらからデータを読み取ります。
1つのスレッドを開始します。このスレッドは、無期限のループで新しい接続をリッスンし、1つのソケットからデータを読み取るクライアントごとに新しいスレッドを開始します。
約100のクライアントでいくつかのテストを行いましたが、両方のアーキテクチャのパフォーマンスに違いは見られませんでした。それで、私はあなたの意見を聞きたいです、どちらの方法が良いですか。ありがとうございました！
これはすべて、ゲームが実際にどれだけリアルタイムであるかに依存します。
最初のアプローチでは、開いているすべてのソケットでイベントの逆多重化を実装します。おそらく、select()またはpoll()を使用してブロックします。明らかに、ブロックされている間のみイベントの通知を受信でき、ブロックを解除したときに複数のイベントが配信された場合は、各イベントの処理を効果的にシリアル化します。
2番目のアプローチでは、イベントを並行して処理し（特にマルチプロセッサシステムで）、スレッドの優先順位を使用して接続に優先順位を付ける可能性があります。ただし、このアプローチはより多くのメモリを使用し、スレッドのスケジューリングは、最初のアプローチでイベントのリストを反復処理するよりもかなりコストがかかります。
自分自身に尋ねる必要がある質問は次のとおりです。
私の意見では、それはあなたがあなたにとってより簡単であるとあなたが信じるものに依存します。
ブーストを使用していますか？はいの場合は、そのasioようなサーバーアーキテクチャを実装するための使用例を確認できます。このようにして、接続をリッスンして要求を処理するときにスレッドを手動で管理することを回避できます。
また、サーバーアーキテクチャを簡単に実装するために特別に作成されたライブラリであるZeroMQもあります。これを使用すると、スレッドの数などを明示的に制御することで、さらに詳細なケースをテストできます。
お役に立てれば。
WebSocketにアクセスしたい場合は、ここに簡単なヒントがあります。https ：//github.com/zaphoyd/websocketppを参照するか、作成者（Peter）に質問してください。WebSocket ++には、WebSocket処理をどのように/どのように行うかに関して非常に柔軟なフレームワークがあります。
経験に基づいて、新しいクライアント用に別のスレッドを用意して、サインインを処理し、ゲームに参加するための良いポイントを待つようにします。サインインする新しいプレーヤーのためにゲームを中断したいとは限らないと思います。そうしないと、1つのマスタースレッドがかなり乱雑になる可能性があります。
また、8つ以上のコアが使用可能な場合は、ゲームごとに1つなど、スケーラビリティのためにスレッドグループに複数の既存のゲームスレッドが必要になる場合があります。スケーラビリティをさらに高めるために、新しいゲームスレッドから別のサーバーにリダイレクトすることも検討してください。
Boost.Asioを使用して、幸せになりましょう。いくつかの例を学び、ネットワークの基本ではなく、実際にゲームを作り始めてください。