Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!pasteur!ucbvax!asylum.UUCP!romkey
From: romkey@asylum.UUCP (John Romkey)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Call queueing
Message-ID: <8808272045.AA13737@asylum.UUCP>
Date: 28 Aug 88 03:45:59 GMT
References: <626@root44.co.uk>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Asylum; Belmont, CA
Lines: 19

jgh@root.co.uk asked about why listen(2) allows a queue of pending
connection requests.

Under the BSD networking model, when you want to listen() for a
connection, you first get a socket and then listen() on it. When a
connection is opened, you do an accept() (which gets you a new socket)
to actually get ahold of the connection. A server which wants to be
able to handle more than one connection at a time normally fork()s,
and the child process does the actual work while the parent goes back
to listen()ing.

If you don't allow a queue of pending requests, then from the time
when the listen() completes to the time when the server issues a new
listen(), there is no one listening. Any incoming requests will then
get a reset. The window of time is probably pretty small, on the order
of milliseconds, but you want it to be 0. So you need listen() to be
able to handle more than one incoming request. And you have to tell
listen() how many to handle so that the kernel can allocate
appropriate resources.
				- john romkey