Udp Receive Queue Full

How to monitor Linux UDP buffer available space?

Linux provides the files /proc/net/udp and /proc/net/udp6, which lists all open UDP sockets (for IPv4 and IPv6, respectively). In both of them, the columns tx_queue and rx_queue show the outgoing and incoming queues in bytes.

If everything is working as expected, you usually will not see any value different than zero in those two columns: as soon as your application generates packets they are sent through the network, and as soon those packets arrive from the network your application will wake up and receive them (the recv call immediately returns). You may see the rx_queue go up if your application has the socket open but is not invoking recv to receive the data, or if it is not processing such data fast enough.

limiting the number of udp packets in send queue

To change the size of the kernel send socket buffer (in bytes), use SO_SNDBUF.

The default behavior is blocking, but you can modify this so the socket is non-blocking (with the SOCK_NONBLOCK option on the socket call). Otherwise, you could set O_NONBLOCK with an fcntl call.

Then, you'd get back an error code of EAGAIN/EWOULDBLOCK instead of blocking on your send call.

You can also use either select or poll syscalls to control waiting.

There are also ioctl calls to check the current number of bytes in the queue, such as TIOCINQ for the receive queue or TIOCOUTQ for the send queue.

Note that, again, because you're using UDP, none of the above would guarantee delivery through the network as any other node in the path could drop the packet(s). The above only guarantees that the originating node won't drop due to buffer overflow.

What is [usually] more useful is to increase the size of the corresponding kernel receive buffer with SO_RCVBUF to allow large bursts to be received without the kernel dropping as much. Because of UDP, this is not a guarantee that the local node will not drop anything, but it can limit the number of drops.

How long does a UDP packet stay at a socket?

Normally, the data will be buffered until it's read. I suppose if you wait long enough that the driver completely runs out of space, it'll have to do something, but assuming your code works halfway reasonably, that shouldn't be a problem.

A typical network driver will be able to buffer a number of packets without losing any.

Does C# UDP socket's ReceiveBufferSize applies to size of datagrams or size of the message queue?

Presumably you mean UdpClient.Client.ReceiveBufferSize, i.e. Socket.ReceiveBufferSize?

If you chase that call through, you end up at a call to setsockopt here, with the SO_RCVBUF option.

Researching that option, you end up at this answer from @DS:

SO_RCVBUF is simpler to understand: it is the size of the buffer the kernel allocates to hold the data arriving into the given socket during the time between it arrives over the network and when it is read by the program that owns this socket. With TCP, if data arrives and you aren't reading it, the buffer will fill up, and the sender will be told to slow down (using TCP window adjustment mechanism). For UDP, once the buffer is full, new packets will just be discarded.

That suggests it's the size of the entire queue associated with the socket, i.e. how large the buffer that the OS will put received UDP datagrams into for you to read is. Once this is full, additional datagrams will be discarded.

---

Related Topics