Specifying Udp Receive Buffer Size at Runtime in Linux

Specifying UDP receive buffer size at runtime in Linux

You can increase the value from the default, but you can't increase it beyond the maximum value. Use setsockopt to change the SO_RCVBUF option:

int n = 1024 * 1024;
if (setsockopt(socket, SOL_SOCKET, SO_RCVBUF, &n, sizeof(n)) == -1) {
  // deal with failure, or ignore if you can live with the default size
}

Note that this is the portable solution; it should work on any POSIX platform for increasing the receive buffer size. Linux has had autotuning for a while now (since 2.6.7, and with reasonable maximum buffer sizes since 2.6.17), which automatically adjusts the receive buffer size based on load. On kernels with autotuning, it is recommended that you not set the receive buffer size using setsockopt, as that will disable the kernel's autotuning. Using setsockopt to adjust the buffer size may still be necessary on other platforms, however.

Linux UDP max size of receive buffer

It seems that there is a limit in linux.
I have tried setting rmem_max to 2^32-1 with success.

   root@xxx:/proc/sys/net/core# echo 2147483647 > rmem_max
   root@xxx:/proc/sys/net/core# cat rmem_max
   2147483647

2^32 was too much:

   root@xxx:/proc/sys/net/core# echo 2147483648 > rmem_max
   root@xxx:/proc/sys/net/core# cat rmem_max
   -18446744071562067968

Setting to 5000000000 yields:

   root@xxx:/proc/sys/net/core# echo 5000000000 > rmem_max
   root@xxx:/proc/sys/net/core# cat rmem_max
   705032704

I have tested in python that setting and getting socket receive buffer with

   ss.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, bufferSize)
   print ss.getsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF)

If 'bufferSize' is less then 1024^3 program prints doubled 'bufferSize', otherwise it falls back to 256.

The value 705032704*2 = 1410065408 is close to the 1409995136 obtained by netstat.

Need a dynamic size buffer when listening to a udpsocket

Now, the length of my data will vary and I cannot give a size like "2048"

Do you have packed the length information of your data into the packet data? For example, the leading 4 bytes containing the length of the entire packet.

If you have such information, you could use the UdpSocket::peek:

Receives single datagram on the socket from the remote address to which it is connected, without removing the message from input queue. On success, returns the number of bytes peeked.

Then you could get the length as a number, then allocate exactly the right amount of space and call.

But everything comes with a tradeoff, it needs an extra system call, which could be more expensive than getting some space from the stack.

Or, you could, just simply allocate a "big enough" array ahead of time.

udp socket receive buffer size

You seem to have misread the output. When you line up the columns properly, rx_queue is zero.

UDP Server Socket Buffer Overflow

Having socket reading at fixed interval of four seconds definitely sets you up for losing packets. The conventional tried-and-true approach to non-blocking I/O is the de-multiplexer system calls select(2)/poll(2)/epoll(7). See if you can use these to capture/react to your other events.

On the other hand, since you are already using threads, you can just do blocking recv(2) without that four second sleep.

Read Stevens for explanation of SO_RCVBUF.

---

Related Topics