From: Archie Cobbs <archie@tribe.com>
Message-Id: <199512132105.NAA26701@bubba.tribe.com>
Subject: listen(2) semantics
To: freebsd-hackers@freebsd.org
Date: Wed, 13 Dec 1995 13:05:32 -0800 (PST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: owner-hackers@freebsd.org
Precedence: bulk


I'm confused about the "backlog" parameter of the listen(2)
system call... I have a program which calls "listen(sock, 0)",
specifying a maximum pending connection queue length of zero.

Now here's what the man page says:

  The backlog parameter defines the maximum length the queue of
  pending connections may grow to.  If a connection request arrives
  with the queue 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 retries may succeed.

However, the observed behavior is this: the first connection succeeds
and data is exchanged, the second connection "succeeds" but no data
is read by the server (until the first connection exits), and the third
connection fails via mode 2 described above.

My question is how come the second connection doesn't fail via mode 2?
Why does it say "connected to ..." when it's not really connected
and the queue of pending connections supposedly has length zero? It
seems like it ought to fail if someone is already connected.

I.E, which of the following is the case and why :-)

 1 I'm misinterpreting the man page
 2 The man page is inaccurate
 3 The implementation of listen(2) is wrong

Example:

  $ telnet localhost 6006
  Trying 127.0.0.1...
  Connected to localhost.tribe.com.
  Escape character is '^]'.

  ^]
  telnet> ^Z
  Suspended
  $ telnet localhost 6006
  Trying 127.0.0.1...
  Connected to localhost.tribe.com.
  Escape character is '^]'.

  ^]
  telnet> ^Z
  Suspended
  $ telnet localhost 6006
  Trying 127.0.0.1...            <-- hangs, failing via mode 2
  ^C

Thanks,
-Archie

_______________________________________________________________________________
Archie L. Cobbs, archie@tribe.com  *  Tribe Computer Works http://www.tribe.com