最初は、プレーヤーがいるソケットを使用することを考えていました
サーバーにリクエストを送信すると、サーバーはリクエストを処理し、応答を送信します。または、プレーヤーは、ゲームの状態の変更に関するクエリを頻繁に送信する必要がある場合があります。
これは最悪の考えですか？
2 番目の質問は、サーバー側のコードに関するものです。現在、各着信接続は、そのタスクを実行するために新しいスレッドを生成します。主に、ハード ドライブからいくつかのファイルを読み取り、応答としてそれを要求した Android デバイスに文字列を送り返します。
しかし、スケーラビリティについては疑問です。たとえば、100 万人のプレイヤーが毎分 10 秒間ソケット スレッドを開いているとします。常に 20,000 の同時スレッドが実行され、ハードドライブ ファイル IO プロセスを使用する必要がある場合があります...
これが明らかに非現実的である場合、どのような代替案を提案しますか? ありがとう、申し訳ありませんが、ネットワークなどでこれまでに試みたことはありません。
簡単なゲームをするだけでも、Message Broker の使用を検討します。パッケージのオーバーヘッドでネットワーク トラフィックが追加されますが、信じられないほど柔軟でスケーラブルです。
メッセージングの Request-Reply パターンを見てください。
http://www.eaipatterns.com/RequestReply.htmlhttp://www.eaipatterns.com/RequestReply.html
と
この特定のブローカーの RPC とトピックのチュートリアルを確認してください。
http://www.rabbitmq.com/java-client.html
特定のクライアントを交換上の任意のトピックにサブスクライブでき、実行時に変更できます。ゲームを探しているクライアントのトピックを想像し、それらを独自のトップまたはキューに移動します。
意図的ではないことは承知していますが、TCP/IP に対するソケットよりも最新の抽象化レイヤーであると考えてください。やりたいことの多くはすでに完了しており、楽しいことにもっと時間を割くことができます。:-)
ThreadPool を使用することをお勧めします: http://www.javamex.com/tutorials/threads/ThreadPoolExecutor.shtml
これにより、スレッドの作成と破棄を続ける必要はありませんが、多くのスレッドが常に存在し、タスクを待っています。これにより、スレッドの作成と破棄のオーバーヘッドが回避されます。
IO に関しては、複数のスレッドから同時に同じディスクを読み取ることは避けたいと考えています。これは、ハード ドライブがある場所から別の場所へのシークに時間を浪費する原因となるためです。ファイルの読み取りをシリアルに管理するクラスを実装することで、これを解決します。各スレッドは、このクラスにリクエストを送信して特定のファイルを読み取り、ファイルが読み取られたときに呼び出されるコールバック メソッドを提供できます。次に、コールバックでファイルを処理し、応答を電話に送り返すことができます。これにより、2 つのスレッドで誤って同じファイルに書き込むこともなくなります。
この回答は、コールバックを使用してタスクを実装する方法を示しています: https://stackoverflow.com/a/443741/1675231
それが役に立てば幸い。