-3

私が取り組んでいる一般的なターンベースのゲームがあり、現在その動作方法は次のとおりです。boneCP (接続プール)、MySQL データベース、Java サーバー、Android クライアント、およびすぐにスレッドプールを使用します。

クライアントがサーバーにリクエストを送信します。Java サーバーは、要求を処理するために新しいスレッドを生成します。サーバーが応答を送信します。TCP ソケットが終了します。

各クライアントは、永続的な (長期的な) 接続の負荷を維持するのではなく、単純に (x) 間隔ごとにサーバーを突いて、自分の番かどうかを尋ねます。いいえの場合、何もしません。はいの場合、入力して移動をサーバーに送信できます。

このタイプのサーバープロディング ネットワーキングでは、すべてを NIO に変換することで何らかのメリットが得られるでしょうか? クライアントは通常、TCP ソケットを介して数行のテキストなど、非常に小さなデータのみを送信します。サーバーが大きなファイル (画像、音声、ビデオ) をクライアントに送信することはめったにありません。このアプリケーションで IO/NIO を使用することについて、他に何か考えはありますか? これにより、作成されたスレッドの最大数でボトルネックが取り除かれ、スケーラビリティが拡張されるのではないかと思います.1秒程度しか持続しない場合でも.

編集: また、注意: プレイヤー A が 30 ～ 60 秒以上待ってからターンを行うと、そのターンは没収されます。したがって、無限ループでサーバーを永遠に突っ込んでいるわけではありません。せいぜい5秒間隔で数回です。また、ゲームが没収されるまでのターン没収回数には上限があります。

4

2 に答える 2

2

このような同期アプローチの代わりに、イベントベースの方法をお勧めします。

while ループでクライアントを何千回もチェックする代わりに、はるかに効率的でスケーラブルなイベント ループでチェックすることができます。

于 2013-06-08T09:08:46.857 に答える
1

最大スレッドのボトルネックを回避するには、スレッド プールを使用できます。これは、NIO 2 非同期 IO クラスを使用して行うことができます。

class ConnectionConext {}

class Handler implements CompletionHandler<Integer,ConnectionConext > {
public void completed(Integer result, ConnectionConext conn) {
// handle result
}
public void failed(Throwable exc, ConnectionConext conn) {
// error handling
}
}

//using executor's thread pool
ExecutorService executor = ...
//consider other withFixedThreadPool, or withCachedThreadPool
AsynchronousChannelGroup group = AsynchronousChannelGroup
.withThreadPool(executor);

AsynchronousSocketChannel channel =
AsynchronousSocketChannel.open(group);

ByteBuffer buf = ByteBuffer.allocate(...);//consider to use ByteBuffer pool for better scalability
ConnectionConext conn = ..//some connection info that will be passed to completion handler.
Handler handler = ...

ch.read(buf, conn, handler);

便利なものについては、 Grizzly Projectも検討してください。

于 2013-06-08T10:23:51.173 に答える