12

NIO と TCP は、多くの接続に最適な組み合わせです。新しいクライアントごとに新しい接続を開く必要があるため、通常、これらの各クライアントには、I/O 操作をブロックするための独自のスレッドが必要です。NIO は、データが使用可能になるまでブロックするのではなく、可能なときにデータを読み取れるようにすることで、この問題に対処します。しかし、UDP はどうでしょうか。

つまり、コネクションレス UDP には、プロトコルの設計方法 (基本的には送信して忘れる) が原因で、TCP のようなブロッキングの性質が関連付けられていません。データをあるアドレスに送信することにした場合、(サーバー側で) 遅延なく送信されます。同様に、データを読み取りたい場合は、さまざまなソースから個々のパケットを受信するだけです。それぞれを処理するために多くのスレッドを使用して、多くの場所に多くの接続を行う必要はありません。

では、NIO とセレクターはどのように UDP を強化するのでしょうか? java.netより具体的には、古いパッケージではなく、NIO で UDP を使用することを好むのはいつですか?

4

2 に答える 2

9

メソッドDatagramSocket.receive(...)はブロッキング操作として文書化されています。たとえば、N 個の異なるソケットからのパケットを処理しようとする 1 つのスレッドがある場合、NIO とセレクターを使用する必要があります。同様に、スレッドが新しいパケットのチェックを他のアクティビティと多重化する必要がある場合は、これを行うことができます。

これらまたは同様の要件がない場合、セレクターは役に立ちません。しかし、それは TCP の場合と変わりません。余分なシステム コールが追加される 可能性があるため、不要な場合は TCP でセレクターを使用しないでください。

select(Linux では、データグラムの場合、recv単にrecv.

しかし、1 つの DatagramSocket しか扱っていない場合、受信メソッドは、パケットが別のコンピューターからのものであるにもかかわらず、パケットが到着するとすぐに読み取るのではないでしょうか?

「全員」からのデータグラムを1つのソケットでリッスンしている場合は、そうです。コンピューターごとに異なるソケットがある場合は、いいえ。

また、TCP のコメントについては、ブロックしている TCP サーバーで要求されるように、何千ものスレッドを持つことは非常にリソースを必要とするという事実によって、セレクターの使用が正当化される場合があります。

私たちはその事件について話し合っていませんでした。しかし、はい、それは本当です。また、UDP 受信をブロックするスレッドが何千もある場合も同様です。

私の要点は、多くのスレッドがない場合、またはスレッドがブロックされても問題ない場合、NIO は役に立たないということでした。実際、パフォーマンスが低下する可能性があります。

于 2013-04-16T23:05:33.843 に答える
4

NIO は、スレッドの必要性を完全に取り除きます。TCP クライアントと UDP クライアントの両方を含む、すべてのクライアントを 1 つのスレッドで処理できます。

コネクションレス UDP には、それに関連付けられた TCP のブロッキング特性がありません

それは真実ではない。少なくとも理論的には、受信は引き続きブロックされ、送信もブロックされます。

于 2013-04-17T00:05:24.010 に答える