What is the purpose of the SO_SNDLOWAT socket

Question

I am currently porting C software from Tru64 to Linux Suse 11. On Tru64, they set the SO_SNDLOWAT option SO_SNDLOWAT socket 1024 * 64 . On Linux, this option has not been changed, and its value is 1.

I want to find out what the impact of non-installation SO_SNDLOWAT at 1024 * 64 on software execution on Linux will be.

The problem is that I found two definitions (interpretations) of the purpose of SO_SNDLOWAT :

• Found on the socket page on Linux:

  SO_SNDLOWAT Specify the minimum number of bytes in the buffer while the socket will transfer data to the protocol

  I realized that it indicates the minimum number of bytes in the buffer to continue (in this case, to send a message). The buffer must be filled, at least for SO_SNDLOWAT bytes, to continue

• Found in the book "UNIX Network Programming: W. Richard Stevens, Bill Fenner, Andrew M. Rudoff Socket Network Interface"

  The low-water send icon is the amount of free space that must exist in the socket send buffer in order to select rewritable.

  I realized that if I want to write in the socket buffer (regardless of the size of what I write), the buffer should have fewer SO_SNDLOWAT bytes.

I do not know what to do with SO_SNDLOWAT .

Answer 1

The first description is the correct interpretation.

Regarding the impact of the inability to set SO_SNDLOWAT , I don’t think it will matter, because performance depends on things like Nagle algorithm, path-MTU detection, etc. I suspect other TCP / IP implementations silently ignore this option.

Answer 2

Afaik is the second correct, but I could never use it.

SO_SNDLOWAT cannot be changed on Linux. setsockopt not working with error ENOPROTOOPT

Answer 3

As you can see on this question , which covers other socket options, the answer depends on the operating system, so both answers may be correct, since one of them is a response from the Linux world, and one of them answers from the UNIX world (BSD and Co) .

In the BSD and BSD clone, this parameter means the following:

• If the socket is non-blocking and you call send() , it should be able to accept all the data provided at the same time or receive at least SO_SNDLOWAT data bytes; if this is not possible, it does not accept any data, and send() fails with an error.

  So, if you set SO_SNDLOWAT to 100 and try to send 50 bytes, it will send 50 bytes or nothing. If you set SO_SNDLOWAT to 100 and try to send 200 bytes, it should at least receive 100 bytes of data, it can take more, up to 200 bytes, and also any value from 100 to 200, not less than 100. Keep in mind that the default value of SO_SNDLOWAT is 1, as well as the default behavior of a non-blocking socket (it should take at least 1 byte or crash with EWOULDBLOCK )

  Please note that UDP sockets are always all or nothing, they never accept only a “part of the data”, therefore setting SO_SNDLOWAT applicable only for TCP sockets, which can accept only a part of the proposed data.

• If the socket is blocked, setting SO_SNDLOWAT does not have a real effect on the send() call, since in this case the socket will always accept all data or it will be blocked, and then it will be blocked until all the data (if the send timeout has been set using SO_SNDTIMEO or the underlying protocol has its own timeout to send).

• Regardless of whether the socket is blocked or not, regardless of whether it is UDP or TCP, the poll() or select() call will state that this socket is writable if at least SO_SNDLOWAT bytes can be received by the send() call .

So why is this option really good? It is usually used to avoid your process supplying data in bytes for a byte after the socket buffer is full, but in large fragments, as with the default behavior, select() and poll() will say that the socket is available for entries, even if there is one byte in the socket buffer. In other words, it’s just a performance optimization, because code that works correctly with arbitrary socket SO_SNDLOWAT will work correctly, regardless of whether SO_SNDLOWAT is SO_SNDLOWAT and no matter what value, it may take much less CPU time in some extreme situations. if SO_SNDLOWAT is reasonable. But, like in all performance settings, if you do not know exactly what you are doing, you can easily aggravate the situation by setting the wrong values, so if in doubt, do not touch this setting.