Post by Scott LurndalPost by Lawrence D'OliveiroSome documentation suggests that calling listen(2) with a negative backlog
is equivalent to setting it to the maximum possible value. But this is not
documented in any place I’m aware of (e.g.
<manpages.debian.org/2/listen.en.html>).
That page does not mention EINVAL as a possible return status, so perhaps
such out-of-range values are acceptable and will be interpreted reasonably
after all?
If this is true, then there is no need to bother determining the explicit
value of SOMAXCONN.
"The backlog argument provides a hint to the implementation
which the implementation shall use to limit the number of
outstanding connections in the socket's listen queue. Implementations
may impose a limit on backlog and silently reduce the specified value.
Normally, a larger backlog argument value shall result in a larger
or equal length of the listen queue. Implementations shall support
values of backlog up to SOMAXCONN, defined in <sys/socket.h>."
There's no need to determine the explicit value of SOMAXCONN (128 on
my fedora core installation sys/socket.h). There's no requirement
for the implementation to honor the backlog argument, it's just
a hint.
The Linux Programmer's Manual listen(2) manpage says
"If the backlog argument is greater than the value in
/proc/sys/net/core/somaxconn, then it is silently truncated to that value;
the default value in this file is 128. In kernels before 2.4.25, this limit
was a hard coded value, SOMAXCONN, with the value 128."
Yes, the backlog argument is a /hint/, but (apparently) a hint that the
linux kernel takes seriously. And, Lawrence is correct in both his statements
and his implications:
a) in Linux, /proc/sys/net/core/somaxconn authoritatively represents the value
of the maximum number of backlogged connections, while the value of SOMAXCONN
in <sys/socket.h> does not (although SOMAXCONN represents the /default/
value of /proc/sys/net/core/somaxconn)
b) in Linux, /proc/sys/net/core/somaxconn can be increased or decreased dynamically,
meaning that SOMAXCONN does not represent the "current" state of the maximum
number of backlogged connections.
c) to be accurate, a linux program should retrieve the backlog maximum by reading
/proc/sys/net/core/somaxconn, rather than depending on the value of SOMAXCONN
from <sys/socket.h>
d) (My observation) a linux program cannot accurately determine the backlog maximum,
as it might change (either up or down) /after/ the program reads /proc/sys/net/core/somaxconn
In this case, the programmer could just accede to POSIX, and obtain the default
value from <sys/socket.h>, unless the true current maximum is required.
--
Lew Pitcher
"In Skills We Trust"