Sockets for Clients - Java Network Programming - page 263

public int getReceiveBufferSize () throws SocketException
public void setSendBufferSize ( int size )
throws SocketException , IllegalArgumentException
public int getSendBufferSize () throws SocketException
Although it looks like you should be able to set the send and receive buffers independ‐
ently, the buffer is usually set to the smaller of these two. For instance, if you set the send
buffer to 64K and the receive buffer to 128K, you'll have 64K as both the send and receive
buffer size. Java will report that the receive buffer is 128K, but the underlying TCP stack
will really be using 64K.
The setReceiveBufferSize() / setSendBufferSize methods suggest a number of bytes
to use for buffering output on this socket. However, the underlying implementation is
free to ignore or adjust this suggestion. In particular, Unix and Linux systems often
specify a maximum buffer size, typically 64K or 256K, and do not allow any socket to
have a larger one. If you attempt to set a larger value, Java will just pin it to the maximum
possible buffer size. On Linux, it's not unheard of for the underlying implementation to
double the requested size. For example, if you ask for a 64K buffer, you may get a 128K
buffer instead.
These methods throw an IllegalArgumentException if the argument is less than or
equal to zero. Although they're also declared to throw SocketException , they probably
won't in practice, because a SocketException is thrown for the same reason as Ille
galArgumentException and the check for the IllegalArgumentException is made
first.
In general, if you find your application is not able to fully utilize the available bandwidth
(e.g., you have a 25 Mbps Internet connection, but your data is transferring at a piddling
1.5 Mbps) try increasing the buffer sizes. By contrast, if you're dropping packets and
experiencing congestion, try decreasing the buffer size. However, most of the time,
unless you're really taxing the network in one direction or the other, the defaults are
fine. In particular, modern operating systems use TCP window scaling (not controllable
from Java) to dynamically adjust buffer sizes to fit the network. As with almost any
performance tuning advice, the rule of thumb is not to do it until you've measured a
problem. And even then you may well get more speed by increasing the maximum
allowed buffer size at the operating system level than by adjusting the buffer sizes of
individual sockets.
SO_KEEPALIVE
If SO_KEEPALIVE is turned on, the client occasionally sends a data packet over an idle
connection (most commonly once every two hours), just to make sure the server hasn't
crashed. If the server fails to respond to this packet, the client keeps trying for a little
more than 11 minutes until it receives a response. If it doesn't receive a response within
12 minutes, the client closes the socket. Without SO_KEEPALIVE, an inactive client