Java 中非阻塞 UDP I/O 与阻塞 UDP I/O
NIO 中的非阻塞 TCP/IP SocketChannel 和 Selector 帮助我用少量线程处理许多 TCP/IP 连接。 但是 UDP DatagramChannels 怎么样？ （我必须承认我对 UDP 不是很熟悉。）
即使 DatagramChannel 未在阻塞模式下运行，UDP 发送操作似乎也不会阻塞。 是否真的存在 DatagramSocket.send(DatagramPacket) 由于拥塞或类似原因而阻塞的情况？ 我真的很好奇是否存在这种情况以及生产环境中存在哪些可能的情况。
如果 DatagramSocket.send(DatagramPacket) 实际上没有阻塞，并且我不打算使用连接的 DatagramSocket 并仅绑定到一个端口，那么使用非- 使用DatagramChannel 和Selector 进行阻塞模式？
Non-blocking TCP/IP SocketChannels and Selector in NIO help me to handle many TCP/IP connections with small number of threads. But how about UDP DatagramChannels? (I must admit that I'm not very familiar with UDP.)
UDP send operations don't seem to block even if the DatagramChannel is not operating in blocking mode. Is there really a case where DatagramSocket.send(DatagramPacket) blocks due to congestion or something similar? I'm really curious if there's such a case and what the possible cases exist in a production environment.
If DatagramSocket.send(DatagramPacket) doesn't actually block and I am not going to use a connected DatagramSocket and bind to only one port, is there no advantage of using non-blocking mode with DatagramChannel and Selector?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我已经有一段时间没有使用Java的DatagramSockets、Channels之类的东西了，但我仍然可以给你一些帮助。
UDP 协议不像 TCP 那样建立连接。 相反，它只是发送数据并忘记它。 如果确保数据实际到达那里很重要，那么这是客户的责任。 因此，即使您处于阻塞模式，您的发送操作也只会在刷新缓冲区时阻塞。 由于 UDP 对网络一无所知，因此它会尽早将其写出，而不检查网络速度或是否确实到达了它应该去的地方。 因此，对您来说，该通道似乎实际上已立即准备好进行更多发送。
It's been a while since I've used Java's DatagramSockets, Channels and the like, but I can still give you some help.
The UDP protocol does not establish a connection like TCP does. Rather, it just sends the data and forgets about it. If it is important to make sure that the data actually gets there, that is the client's responsibility. Thus, even if you are in blocking mode, your send operation will only block for as long as it takes to flush the buffer out. Since UDP does not know anything about the network, it will write it out at the earliest opportunity without checking the network speed or if it actually gets to where it is supposed to be going. Thus, to you, it appears as if the channel is actually immediately ready for more sending.
UDP 不阻塞（仅在将数据传输到操作系统时阻塞）
这意味着如果在任何时候下一跳/交换机/机器无法缓冲 UDP 数据包，它就会丢弃该数据包。 在某些情况下，这可能是理想的行为。 但这是您需要注意的事情。
UDP 也不保证
然而，UDP 确实支持多播，因此可以将相同的数据包传送到一台或多台主机。 然而，发送者不知道是否有人收到数据包。
UDP 的一个棘手问题是它在大多数情况下都能工作，但有时会以难以重现的方式严重失败。 因此，即使您做了一些测试并且看起来有效，您也不应该假设可靠性。
UDP doesn't block (It only blocks while it is transferring the data to the OS)
This means if at any point the next hop/switch/machine cannot buffer the UDP packet it drops it. This can be desirable behaviour in some situations. But it is something you need to be aware of.
UDP also doesn't guarantee to
However UDP does support multicast so the same packet can be delivered to one or more hosts. The sender has no idea if anyone receives the packets however.
A tricky thing about UDP is it works most of the time, but fails badly sometimes in ways which are very difficult to reproduce. For this reason, you shouldn't assume reliability even if you do a few tests and it appears to work.
非阻塞 UDP 在接收端最有用。
数据包发送只能因本地情况而延迟：诸如“游戏网卡”之类的本地流量整形工具（将游戏流量优先于其他流量源）或过载的网卡（这种情况不太可能发生）可能会延迟数据包的发送。 一旦脱离系统。 一旦数据包离开本地接口，应用程序就不再关心它了。
Non blocking UDP is mostly useful on the receiving side.
Packet sending can only be delayed due to local circumstances: local traffic shaping tools like "gaming network cards" that prioritize gaming traffic over other traffic sources, or overloaded network card (which is not likely to happen) can delay the sending of a packet. Once out of the system. Once the packet leaves the local interface, it's no longer the application's concern.