NOTE: I hope this is not a double-post! I tried posting before I had joined, not realizing that I had not joined yet.
I really tried hard googling. No success. I am trying to do an appropriate implementation of a UDP "sender" that sends lots of UDP packets to many different locations. What I think I should do is open several any-port UDP sockets on this machine, and bind a thread to each one. The threads all receive byte[] (etc) of non-zero length size, and destination ipaddr tuples in a queue. Of course, while the queue is empty the threads wait for another addition to the queue. As the queues of the threads get flooded, they drain and send the udp packets as fast as the can to the appropriate destination ipaddrs. The big question is this: does the underlying implementation of DatagramSocketImpl.send() (whose code I couldn't locate googling, and might be native anyways, I don't know), do busy looping on a flag of the UDP protocol? I.e. does it optimally leverage java threading, during the byte by byte xfer process and handshaking, so that other java threads can do useful work, or while it is sending a specific packet, does it block all other threads on that cpu? Similarly, in DatagramChannel, it is not clear of blocking mode means that it busy waits internally. For example, the non-blocking examples of sending DatagramChannel packets say, while the ByteBuffer is not completely sent, do useful work here and then try again. That's not an easy coding model, because the only reasonable solution is Thread.sleep(for_how_long) between successive attempts to send pieces of the ByteBuffer, and that may not scale to all the UDP traffic being sent. Thus I would hope that I can use DatagramSocket.send(), in a thread of highish priority, and be confident that during the internals of the send impl, its not eating all the cpu time on the core on which that thread is running.
