2011-07-30 14 views
0

私は、複数のプレーヤーを同時に接続すると、私の(マルチスレッドの)サーバーにこの奇妙な問題があります.FlashWriterはflush()またはprint()を終了するのに100秒以上(2分)以上かかることがあります。PrintWriter verry slow flush()およびprint()。マルチスレッドとソケット。

public static void send(Player p, String packet) 
{ 
    PrintWriter out = p.get_out(); 
    if(out != null && !packet.equals("") && !packet.equals(""+(char)0x00)) 
    { 
     packet = Crypter.toUtf(packet); 
     out.print((packet)+(char)0x00); 
     out.flush(); 
    } 
} 

のPrintWriterはこのようなものです::私はsend()メソッドにsynchronizedキーワードを追加する場合は、サーバ全体がすべての遅れを開始

_in = new BufferedReader(new InputStreamReader(_socket.getInputStream())); 
_out = new PrintWriter(_socket.getOutputStream()); 

ここ

コードです2秒、私はしない場合、いくつかのランダムなプレイヤーは何の理由も遅れを開始します。

誰でもご存知ですか?これはどこから来たのですか?私は何をすべきか?

+0

クライアントを制御することができないため、任意の数のクライアントが読み込みを停止するか、許容できないほど遅くなることが想定されます。これが起こるとき、あなたはこれをどのように処理するのか考える必要があります。クライアントがデータをすばやく読み取っている場合は、10ミリ秒未満で500接続にフラッシュできます。即ち、バッファは常に自由空間を有する。低速のクライアントが他のすべてのクライアントを減速させることはできません。 –

答えて

1

プリントライターはソケットの出力ストリームにラップされているので、ソケットの出力バッファがいっぱいであると推測して、バッファに十分な余裕があるまで書き込み/フラッシュ呼び出しをブロックしますメッセージが送信されます。

データがクライアントに送信できるよりも速く(クライアントが受信できるよりも速く)データが書き込まれていると、ソケット送信バッファがいっぱいになる可能性があります。

編集:

P.S.スケーラビリティに問題がある場合は、java.nioの代わりにjava.io(ソケットごとに1つのスレッドが必要)を使用している可能性があります(この場合、単一のスレッドが保留中のデータを持つソケットで操作を検出して実行できます) 。 nioは、多数の接続に拡張する必要のあるアプリケーションをサポートすることを意図していますが、プログラミングモデルはより困難です。

+0

あなたが正しいかもしれません。私のデフォルトのバッファサイズは、128 000 IN/49 152 OUTです。それは十分か ?どれくらいですか? – Reacen

+0

バッファのサイズはそれほど重要ではありませんが、ソケットに書き込んでいるレートと、クライアントがデータを送受信できる速度についてです。最初のレートが2番目のレートより大きい場合、呼び出し元は常にブロック/待機します。この場合、あまりにも多くのデータをあまりにも早く送信しようとしている可能性があります。更新レートや送信されるデータの量を減らすことは役に立ちます。 – JimN

0

あなたのsend()メソッドは静的であるため、ソケットに書き込むすべてのスレッドは、そのクラスのオブジェクトで同期化されています。非静的にすると、同じソケットに書き込んでいるスレッドだけが同期されます。

+0

このメソッドはリソースを共有しないユーティリティメソッドのように見えますが、同期は必要ありません。複数の呼び出し元が同時にPlayerインスタンスを操作する場合、呼び出し側は、Playerインスタンスなどの一部のオブジェクトでユーティリティメソッドの外部と同期する必要があります。 – JimN

+0

あなたは正しいです!ありがとうございました!コードが大きすぎるので、たくさんのものを変更する必要がありますが、ありがとうございます。それが単なるスレッド問題であれば問題を解決することを願っています。 – Reacen

関連する問題