3

I have a passive socket that listen connections like this:

t = listen(fd, 1);

fd is the file descriptor of the socket created before.
As you can see and if I understand well, listen() should be able to place only one incoming socket in its queue of pending connections (because its backlog argument = 1). But if I try to connect several sockets to the passive one, I don't get any error. And I expect to have a ECONNREFUSED error because the queue is full.

Why am I missing?

Simon
  • 6,025
  • 7
  • 46
  • 98
  • Did you take a packet capture and verify you are receiving SYN-ACK from the server? – jxh Jun 03 '16 at 08:58
  • The backlog parameter is just a hint, [see this answer](http://stackoverflow.com/questions/5111040/listen-ignores-the-backlog-argument). The effective minimum on Linux seems to be 16. – Karsten Koop Jun 03 '16 at 09:01
  • @jxh no I didn't verify it, what could I conclude if it's the case or not? – Simon Jun 03 '16 at 09:10
  • @KarstenKoop I don't get the point of an argument that it finally replaced by an other value, but Ok. Is there a way to set a max anyway? Or is there a way to programmatically find it? – Simon Jun 03 '16 at 09:13
  • If the SYN-ACK is returned, it probably means the server has allowed the connection request into its listen queue. If not, it is likely the server has dropped the connection request. – jxh Jun 03 '16 at 18:15

1 Answers1

3

As per man listen(2), emphasis mine:

The backlog argument defines the maximum length to which the queue of pending connections for sockfd may grow. If a connection request arrives when the queue is full, the client may receive an error with an indication of ECONNREFUSED or, if the underlying protocol supports retransmission, the request may be ignored so that a later reattempt at connection succeeds.

If you're using TCP sockets, then the behaviour is expected, as TCP supports retransmission.

leovp
  • 4,528
  • 1
  • 20
  • 24
  • So there is no limit using TCP? How can I set one anyway? – Simon Jun 03 '16 at 09:07
  • 1
    From the perspective of a server there is a limit, and it's exactly the number you supply to `listen()`. All the other attempts to connect will be ignored. From the client's perspective it will seem as if a `connect()` simply takes a lot of time. I think implementing timeouts is a good solution so that client code doesn't block indefinitely (or for a long time). – leovp Jun 03 '16 at 09:41