将UDP与NIO结合使用有什么意义？

Question

NIO和TCP为很多连接做出了很好的配对.由于需要为每个新客户端打开一个新连接,因此每个客户端通常都需要自己的线程来阻止I/O操作.NIO通过允许在可能的情况下读取数据来解决该问题,而不是在可用之前阻塞.但是UDP怎么样？

我的意思是,无连接UDP不具有与之关联的TCP的阻塞性质,因为协议的设计方式(基本上是发送并忘记它).如果我决定将某些数据发送到某个地址,那么它会这样做,没有延迟(在服务器端).同样,如果我想读取数据,我只能接收来自不同来源的单个数据包.我不需要与许多地方有很多连接,使用许多线程来处理它们中的每一个.

那么,NIO和选择器如何增强UDP？更具体地说,什么时候人们更愿意使用UDP与NIO而不是ol' java.net包？

Answer 1

那么该DatagramSocket.receive(...)方法被记录为阻塞操作.因此,例如,如果您有一个尝试处理来自N个不同套接字的数据包的线程,则需要使用NIO和选择器.同样,如果线程必须多路复用检查新数据包与其他活动,您可能会这样做.

如果您没有这些或类似的要求,那么选择器将无济于事.但这与TCP案例没有什么不同.如果不需要,则不应将选择器与TCP一起使用,因为它可能会增加额外的系统调用.

(在Linux上,在数据报的情况下,你会做一个select系统调用,后跟一个recv......而不只是一个recv.)

但是如果你只处理一个DatagramSocket,那么接收方法不会在它们到达时立即读取数据包,而不管它们来自不同的计算机吗？

如果您正在一个套接字上侦听来自"everyone"的数据报,那么是.如果你有不同的计算机用于不同的计算机,那么没有.

对于TCP注释,有时候选择器的使用仅仅是因为拥有数千个线程非常需要资源,因为阻塞TCP服务器需要它.

我们没有讨论这个案子.但是,是的,这是事实.如果在UDP接收上有数千个线程阻塞,情况也是如此.

我的观点是,你没有很多线程,或者如果一个线程阻塞无关紧要,那么NIO没有帮助.实际上,它可能会降低性能.