Java7 DatagramSocket.setReceiveBufferSize在Windows和Linux之间有什么不同？

Question

invoking this code on both Linux (Ubuntu 12.04) and Windows 7 you get very different results:

DatagramSocket socket = new DatagramSocket(4445);
socket.setReceiveBufferSize(Integer.MAX_VALUE);
System.out.println("SO_RX_BUFFER SET TO:"+socket.getReceiveBufferSize());

Linux you get: SO_RX_BUFFER SET TO:131071

and on Windows you get: SO_RX_BUFFER SET TO:2147483647

Why the drastic different between operating systems? Why such a small value for linux? Is there anyway to get the linux buffer size up?

Answer 1

What is going on here is that the host operating systems are behaving differently.

• In the Linux case, the OS is placing an upper limit on what you can ask for from an application. To address this, you would need to change the OS configuration settings. That will require "root" privilege and should not be done by an application.

  This page has some basic information on Linux network tuning.

• In the Windows case, the OS either doesn't place a limit or (more likely) it silently overrides the user requested buffer size if it is larger than an OS imposed limit.

---

Having said this, you need think about what you are doing here. Buffered network packets (RX and TX) most likely have to be held in physical memory. When you increase the limits, you are forcing the OS to reserve more RAM pages for itself, reducing the memory available for normal applications.

The second issue is that increasing the amount of network buffering can be harmful if the basic problem is that your application has difficulty keeping up. In the worst case, your application will be continually processing old packets, with new packets being discarded. In short, the extra buffering makes the latency worse without (necessarily) eliminating data loss.

Answer 2

This appears to be a duplicate: Why changing value of SO_RCVBUF doesn't work?

Looks like linux has a config file limit.

Adding the following:

net.core.rmem_max = 16777216 (or whatever you want your limit to be)

to /etc/sysctl.conf

resolved the issue.