Danny Backx (email@example.com)
8 Sep 88 12:09:44 GMT
In article <firstname.lastname@example.org> > jgh@root44.UUCP (Jeremy G Harris) writes:
>> 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
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
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
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 | mail: Danny Backx
Tel: +32 16 200656 x 3544 | Katholieke Universiteit Leuven
Fax: +32 16 205308 | Dept. Computer Science
E-mail: E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A
... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven
dannyb@blekul60.BITNET | Belgium
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:14 GMT