TcpListener issue -- ::listen(getHandle(), 0) never accepts connection

[epezent]

FYI, I was trying to get SFML's TcpListener working on my embedded Linux system. This may be an isolated issue, but

SFML/src/SFML/Network/TcpListener.cpp

Line 83 in 1062e95

if (::listen(getHandle(), 0) == -1)

never allowed a connection. Changing the line to:

if (::listen(get_handle(), SOMAXCONN) == 0)

resolved the issue for me. Like I said, could be an isolated issue on my system. I don't know enough about socket programming to say otherwise, but wanted to give the developers a heads up.

[LaurentGomila]

The behavior of the backLog argument of listen is not clear and apparently highly depends on the underlying OS/kernel.

A backlog of zero should theoretically accept at least one concurrent connection, but I guess it's ok to just use a non-zero value in SFML if it makes everyone happy.

[binary1248]

From here:

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>.

The implementation may include incomplete connections in its listen queue. The limits on the number of incomplete connections and completed connections queued may be different.

The implementation may have an upper limit on the length of the listen queue-either global or per accepting socket. If backlog exceeds this limit, the length of the listen queue is set to the limit.

If listen() is called with a backlog argument value that is less than 0, the function behaves as if it had been called with a backlog argument value of 0.

A backlog argument of 0 may allow the socket to accept connections, in which case the length of the listen queue may be set to an implementation-defined minimum value.

In the case of this embedded system, the implementation-defined minimum value is actually 0, meaning no new connections. I can't tell what practical reasons this can have, but it is still conforming to the specification. Since we don't really care about the backlog at the moment, we should always set it to SOMAXCONN since that is the expected behaviour of sf::TcpListener.