does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait

Andy Nuss
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.
Reply | Threaded
Open this post in threaded view
|

Re: does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait

Paul Marks
On Thu, Dec 14, 2017 at 9:54 AM, Andy Nuss <[hidden email]> wrote:
busy looping on a flag of the UDP protocol?

I believe it's just a blocking sendto():

So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done.

However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good idea.  If you saturate a link in the network, sendto() is not obligated to block, or provide any feedback whatsoever.
Reply | Threaded
Open this post in threaded view
|

Re: does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait

Alan Bateman
On 18/12/2017 21:24, Paul Marks wrote:


So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done.

However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good idea.  If you saturate a link in the network, sendto() is not obligated to block, or provide any feedback whatsoever.
That's right and you'll find that most kernels will just discard the packet so the send never blocks.

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: does the underlying implementation (not public) of DatagramSocketImp's send receive method busy wait

Andy Nuss
Aside from the fact that I should watch out for blasting too many packets at once, and realizing that this one "server/controller" machine has to control 100 or more client receiving machines, with smallish packets, is there any advantage at all relative to the linux kernel in having more than one UDP port open for sending out?  I.e. say the controller has a queue of 200 packets to spray out, is it sufficient to use just one java thread and one UDP outbound port, or would it give the kernel more throughput to send out the packets with 5 threads and 5 sockets or even more? The packets are 10 bytes and/or 140 bytes.
On Tuesday, December 19, 2017, 2:53:30 AM PST, Alan Bateman <[hidden email]> wrote:


On 18/12/2017 21:24, Paul Marks wrote:



So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done.

However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good idea.  If you saturate a link in the network, sendto() is not obligated to block, or provide any feedback whatsoever.
That's right and you'll find that most kernels will just discard the packet so the send never blocks.

-Alan

Reply | Threaded
Open this post in threaded view
|

AW: does the underlying implementation (not public) ofDatagramSocketImp's send receive method busy wait

Bernd Eckenfels-4

Hello,

 

it is a bit unlikely that there is much difference (especially for as low as 200 packets), but I would recommend you actually try it with your specific traffic pattern and System load. Not much a Java developer can say about various Linux kernel versions and their drivers.

 

Gruss

Bernd

--
http://bernd.eckenfels.net

 

Von: [hidden email]
Gesendet: Dienstag, 19. Dezember 2017 15:31
An: [hidden email]; [hidden email]; [hidden email]
Betreff: Re: does the underlying implementation (not public) ofDatagramSocketImp's send receive method busy wait

 

Aside from the fact that I should watch out for blasting too many packets at once, and realizing that this one "server/controller" machine has to control 100 or more client receiving machines, with smallish packets, is there any advantage at all relative to the linux kernel in having more than one UDP port open for sending out?  I.e. say the controller has a queue of 200 packets to spray out, is it sufficient to use just one java thread and one UDP outbound port, or would it give the kernel more throughput to send out the packets with 5 threads and 5 sockets or even more? The packets are 10 bytes and/or 140 bytes.

On Tuesday, December 19, 2017, 2:53:30 AM PST, Alan Bateman <[hidden email]> wrote:

 

 

On 18/12/2017 21:24, Paul Marks wrote:

 

 

 

So if the kernel decides to block, the thread will be suspended (consuming no CPU) until it's done.

 

However, the UDP protocol has no concept of flow control, so blasting out packets without any rate limit or acknowledgement mechanism is not a good idea.  If you saturate a link in the network, sendto() is not obligated to block, or provide any feedback whatsoever.

That's right and you'll find that most kernels will just discard the packet so the send never blocks.

-Alan