Java中非阻塞UDP I/O与阻塞UDP I/O的比较

Question

NIO中的非阻塞TCP/IP SocketChannel和Selector帮助我处理许多线程数较少的TCP/IP连接。但是UDP DatagramChannels怎么样呢？(我必须承认我对UDP不是很熟悉。)

即使DatagramChannel未在阻塞模式下运行，UDP send操作似乎也不会阻塞。是否真的存在由于拥塞或类似原因而导致DatagramSocket.send(DatagramPacket)阻塞的情况？我真的很好奇是否有这样的情况，以及在生产环境中可能存在的情况。

如果DatagramSocket.send(DatagramPacket)实际上不阻塞，并且我不打算使用已连接的DatagramSocket并仅绑定到一个端口，那么对DatagramChannel和Selector使用非阻塞模式是否没有优势

Answer 1

我已经有一段时间没有使用Java的DatagramSockets、Channels和类似的东西了，但我仍然可以给你一些帮助。

UDP协议不像TCP那样建立连接。相反，它只是发送数据，然后忘记它。如果确保数据真正到达那里很重要，那就是客户的责任。因此，即使您处于阻塞模式，您的发送操作也只会在刷新缓冲区所需的时间内阻塞。由于UDP对网络一无所知，因此它会在第一时间将其写出来，而不会检查网络速度或是否实际到达了它应该到达的位置。因此，对于您来说，似乎通道实际上立即准备好进行更多的发送。

Answer 2

UDP不会阻塞(它只在向操作系统传输数据时阻塞)，这意味着如果下一跳/交换机/机器在任何时候不能缓冲UDP数据包，它就会丢弃它。在某些情况下，这可能是理想的行为。但这是你需要注意的事情。

UDP也不保证

按发送顺序传送数据包。不在交换机上分解大型packets.

• forward数据包。
• 。通常会关闭交换机之间的UDP转发。

但是，UDP确实支持多播，因此可以将相同的数据包传送到一个或多个主机。然而，发送者并不知道是否有人接收到了数据包。

关于UDP的一个棘手的事情是，它在大多数情况下都可以工作，但有时会以非常难以重现的方式失败。出于这个原因，即使你做了几个测试，它似乎也是有效的，你也不应该假设它是可靠的。

Answer 3

非阻塞UDP在接收端最有用。分组发送只能由于本地环境而被延迟:本地业务整形工具，如将游戏业务优先于其他业务源的“游戏网卡”，或者过载的网卡(这不太可能发生)可以延迟分组的发送。一旦被排除在系统之外。一旦数据包离开本地接口，它就不再是应用程序关心的问题。