Path: utzoo!attcan!uunet!mcvax!prlb2!kulcs!dannyb
From: dannyb@kulcs.uucp (Danny Backx)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Call queueing
Summary: why does listen exist
Keywords: tcp listen kernel
Message-ID: <128@icarus.kulcs.uucp>
Date: 8 Sep 88 12:09:44 GMT
References: <8808291548.AA14752@violet.ICO.ISC.COM> <628@root44.co.uk>
Reply-To: dannyb@kulcs.UUCP (Danny Backx)
Organization: Katholieke Universiteit Leuven, Dept. Computer Science
Lines: 49

In article <628@root44.co.uk> jgh@root44.UUCP (Jeremy G Harris) writes:
>I asked:
>> The BSD listen(2) syscall (on a socket) provides for the specification
>> of a queue of pending connection requests.  So does the TLI T_LISTEN function.
>
>> What are the pros and cons of this functionality?  Is it merely a matter
>> of the cost of copying a protocol control block versus the cost of opening
>> and initialising one?  Or is there also a functional benefit?
>
>Why does this connection queue have to be handled by the kernel?  Why couldn't
>the application just open and initialise for listening (not in the BSD syscall
>sense)  as many transport endpoints as it's queue needs to be long?

How about this:

A server process S is doing accept. It implements a highly available server.
For speeding things up, it forks of a process for every client.
A client A connects to the socket, and while S is forking, closing the second
socket, and doing the next accept, two client processes B and C have attempted
to connect.

Without a queue, what would happen ? One of the connects could be remembered,
while the second one certainly is forgotten by the kernel that the server runs
on.

Since we're talking about TCP, which is supposed to be reliable, the client
which was forgotten will retry the attempt to connect (after a LONG timeout),
and then probably the connection will be made.

The time interval between the two accept in S is probably small. Therefore,
this situation will not happen very frequently. Still, adding a small
queuing function in the kernel on the accepting side would remove the problem
alltogether.

How about letting the server do a new system call? (Let's call it `listen')
This should eliminate the problem completely.

Disclaimer : I can't claim that this is really the way the listen system call
was invented. I only think this is its only use.

	Danny Backx

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
 Danny Backx                            |  mail: Danny Backx
 Tel: +32 16 200656 x 3544              |        Katholieke Universiteit Leuven 
 Fax: +32 16 205308                     |        Dept. Computer Science
 E-mail: dannyb@kulcs.UUCP              |        Celestijnenlaan 200 A
         ... mcvax!prlb2!kulcs!dannyb   |        B-3030 Leuven
         dannyb@blekul60.BITNET         |        Belgium