問題タブ [socketchannel]

私はこれを理解するのに苦労しています。私は次のコードを持っています：

読み取り用の次のハンドラーコードを使用します。

そして、それがハンドラー関数が呼び出される唯一のポイントです。したがって、becomeReadable()関数に入ると、チャネルは読み取り可能な状態になりますが、read()ブロックへの呼び出しは戻ることはありません。見逃したことはありますか？

コードに問題があります。セレクターを使用して単純な SocketChannel クライアントを作成しました。起動後、サーバーからメッセージを正常に読み取ります (サーバーはイベントを送信します)。しかし、ソケットへの書き込み後 (main メソッドを参照)、selector は無限ループで読み取り可能なソケットを返し始め、handleKey は読み取った -1 バイトを返すため、selector は常に読み取り用のデータなしで OP_READ SelectionKey を返します。私の英語でごめんなさい。

ありがとう。

Java nio を使用する私のプログラムでは、10 KB のメッセージを連続して書き込もうとすると、socketchannel.write() が非常に遅くなります。完全な 10 KB のメッセージを書き込むために測定された時間は、160 ミリ秒から 200 ミリ秒の間です。しかし、完全な 5 KB のメッセージを書き込む時間は 0.8 ミリ秒しかかかりません。

セレクターには、Selection.OP_READ のみがあり、Selection.OP_WRITE は処理されません。大きな完了メッセージが受信されると、別の受信者に 4 回書き込まれます。

会計担当者は誰でも同じ問題を抱えていますか? socketchannel.write() slow に関する投稿があります。私の質問は、OP_READ と OP_WRITE を交互に変更する方法です。

150 ミリ秒などの間隔を追加すると、応答時間が短縮されます。プログラムを待機させることができるように、バッファがいっぱいになったときを見つける方法はありますか。私のオペレーティング システムは Windows XP です。

ありがとう。

書き込まれたバイト数をチェックすることで、EPJ の提案に従います。しかし、応答時間は依然として高いです。ここにコードの一部を投稿し、コードに問題があるかどうかを調べたいと思います。

// これは、nio を使用した writeData() 部分です。

私のアプリケーションには、「送信ネットワーク パケット」( aByteBufferとa を持つ POJO SocketChannel) を持つキューがあり、データを に書き込む単一のスレッドによって消費されますSocketChannel。

これは、パケットを受信する必要があるすべてのクライアントが確実に順番を取得できるようにするためです。これは、SocketChannel.write()複数のクライアントに順番に書き込む (= 一度に 1 つずつ) ことを意味します。

このような作業で何がうまくいかないのか、誰か教えてもらえますか? はSocketChannelsから作成されているServerSocketChannelため、ブロックしています。

write()1 つのクライアントの操作がブロックされ、他のクライアントが待たされるのではないかと心配しています...

これは奇妙に聞こえるかもしれません。ソケット構造ごとのスレッドに基づいてゲーム サーバーを作成しました (はい、ユーザーごとに 1 つのスレッドのみです。応答はワーカー スレッドによってクライアントに送信されます)。私が生成したスレッドは、最初にユーザーを認証してログインを処理します。その後、データを受信して​​処理のためにキューに入れます。認証部分は非常に重要であり、実装に時間がかかり、再度実装するのにも時間がかかるため、認証が完了した後、セレクターができるように、ブロックしているソケットを SocketChannel のソケットに変換できるかどうかを考えていましたメッセージをブロックしない方法で処理しますか?

クライアント側で、コードを読みます:

問題は、socketChannel.read() が常に正を返すことです。リターン バッファを確認しました。データは N 回重複しています。低レベルのソケット バッファの位置が前に移動していないことが好きです。何か案が？

SocketChannelJava 、ServerSocketChannelまたはおそらくDatagramChannelTLS を使用してセキュリティを確保するにはどうすればよいですか?

できると宣伝しているフレームワーク ( #1 #2 )がいくつかあることは知っていますが、純粋な Java 標準ライブラリだけでこれを達成できるかどうかを知りたいです。

プログラムのある時点でスタックするのを避けるために、ノンブロッキング ソケットを読み取ろうとしています。読み込もうとすると常にゼロが返される理由を知っている人はいますか? ByteBuffer の問題でしょうか? この問題は、長さが常にゼロの read メソッドで発生します。

リモートストレージ (iSCSI ターゲット) 用の Java サーバーを作成しました。クライアントは、データ ペイロードを運ぶ一連のパケットを送信することにより、データを書き込むことができます。これらのパケットは、固定長のヘッダー (48 バイト) とそれに続く可変長のデータ セグメントで構成されます。データ セグメントの長さはヘッダーで指定され、固定 (8KiB) と見なすことができます。

データ パケットの受信は、2 つの部分からなるプロセスです。最初に、ヘッダーが 48 バイトのサイズの ByteBuffer に読み込まれます。その直後に、ByteBuffer.allocate(...) を介して 2 番目の ByteBuffer が作成されます。この 2 番目のバッファーのサイズは、ヘッダーで指定されたデータ セグメントの長さと一致します。次に、SocketChannel.read(ByteBuffer) メソッドを使用して、データ セグメントが 2 番目の ByteBuffer に読み込まれます。単純なケースでは、このプロセスは期待どおりに機能します。データ セグメントが大きく、シーケンスが長いほど、IO 速度が向上します。「単純なケース」とは、ブロッキング SocketChannel を使用してパケットを受信 (および処理) する単一のスレッドがあることを意味します。ただし、独自の TCP 接続と関連付けられた SocketChannel を持つ 2 番目のスレッドが追加された場合、SockerChannel.read(ByteBuffer) の実行時間は 2.5 ミリ秒を超えます。一方、クライアント サーバーは両方の接続で 32KiB の書き込みコマンド (つまり、4 つの連続したデータ パケット) を送信しています。これは、8 倍から 10 倍の増加です。

この段階では、2 つのスレッドが同じネットワーク インターフェイス カード以外のリソースを共有していないことを強調したいと思います。各 SocketChannel の読み取りバッファ サイズは 43690 バイトです (これより大きなサイズでも、この現象には影響しませんでした)。

これを引き起こしている可能性のあるアイデア、またはこの問題を修正する方法はありますか?

デバッグコードにAndroidでSocketChannel書き込みが含まれていると、IllegalArgumentExceptionが発生しますが、Windowsで同じコードにこの例外はありません。AndroidとSocketChannel書き込みのWindowsに違いはありますか？

更新:(コードはオープンソースプロジェクトfrostwire-android（githubのこのファイル）の一部であり、この部分はvuze 4.5と同じです、私はただtry {}を追加します）