Home/ Questions/Q 8707477
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-13T03:52:49+00:00

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

  • 0

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?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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.

    • 0