Anyone experience with listen and backlog of '1'

Question

Hi there,

I have an issue: We try to have a 'TCP' server, on port 8100 (at least this issue is equal in NetOs 7.4 and NetOs 7.5). Our requirement is, that only ONE connection from outside should be allowed. Therefore I use the listen call with a backlog of '1'.
From my point of view there a two problems:

• If I use the listen call with the backlog count of '1', I can connect 2 clients (one is accepted, one in the queue), the third one isn't able to connect. If I call 'listen' with '0' no client is allowed to connect (which is OK). It looks strange to me, that only the '1' backlog seems not to work correct
• Regarding the documentation, the second client should get a Connection Refused, but I only see in Wireshark that the client sends three times the SYNC message, and the stack does not respond anything.

Also I tried to use the SOL_SOCKET options for the socket (SO_REUSEADDR and SO_REUSEPORT), but with no luck.
Any ideas?
Thanks in advance

Answer 1

Unfortunately the implementation of listen is very, very platform specific. In addition (according to Stevens) many implementations add a "fudge factor" to the value you specify. Thus, setting the listen backlog value to 1 will, in general, not give you the result you are looking for. Off the top of my head, the only thing I can think of doing would be to implement your tcp server to keep track (on its own) of the number of connections it is aware of. When you go above whatever number your application wants to support, RST all additional connections until the number of current connections goes below your threshold. So if you only want one connection at a time, then once one guy connects, RST all subsequent connections until that first one disconnects. When that first one connects, then your server can allow the next connection to connect.

Answer 2

Hi,

thanks for the answer. The issue with this topic is, that as far as I understand we are only able to first accept the connection, and afterwards reject / reset all additional ones. This is what we are currently doing, but our customer does have problems, if it is first signalized with OK, and afterwards we do a reset (the customer has an issue with the fault handling).
What looks strange to me: If you set this value to '1' it works as described:
The first connection is accepted by our application. If the client requests another connection this is accepted bt not handled (at least it is in the queue of the network stack). If we close the first connection, we get the second one, and all data which is sent to it in the meantime. So I thought I can set this value to '0', but then the first connection is not accepted anyhow. I tried to have a solution, to build up an own internal connection after the first one is established,but this could be to much risk from timing point of view.
So summarize: At least it seems, that something is done with this parameter, but only if it is > 0.
regards