I am using the same UDP socket for sending and receiving data. I am wondering if packet queuing for DGRAM sockets is already present, or do we have to handle it separately.
If the user code has to handle queueing, how is it done? Do we have separate threads to recvfrom for the socket and put the packet in the reciver_queue and to sendto from another sending_queue?
An example code will be absolutely awesome. Thanks for your help.
There is a packet queue. However when the packet queue is filled then UDP packets start getting discarded. When they are discarded they are lost forever so make sure you keep reading data!
As Goz has noted, there is a packet queue. There is more than one, actually, at various places of the whole pipeline that ends in your application. There are usually some buffers on the NIC, then there are some managed by the kernel. The kernel buffers often can be sized for individual sockets using setsockopt().
As Goz has already noted, UDP packets can be lost on their way to you, or they can arive in different order. If you need both realiability and ordering and if you cannot use TCP instead, you will have to implement some kind of protocol that will provide both atop UDP, e.g. sliding window protocol.
With UDP there's actually only the receive socket buffer. While there is SO_SNDBUF socket option, the value supplied is just the upper limit for the datagram size. The outbound datagram is either given to the hardware in whole, or in fragments (if it's bigger then the MTU), or discarded. The hardware usually have some ring buffers, but that really has to do with DMA and of no concern to userland apps.
The most straightforward technique for packet queueing in the application is, again, a circular buffer - make it large enough for normal usage, lose some packets during heavy spikes. Surely there are other approaches.