Non-blocking TCP/IP SocketChannel
s and Selector
in NIO help me to handle many TCP/IP connections with small number of threads. But how about 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.
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.
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.