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?
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 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
- delivery packets in the order they are sent.
- not to break up large packets.
- forward packets across switches. Often UDP forwarding between switches is turned off.
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.
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.
来源：https://stackoverflow.com/questions/569555/non-blocking-udp-i-o-vs-blocking-udp-i-o-in-java