listen


jam@radc-lonex.arpa
Thu, 8 Sep 88 13:58:34 EDT


> My thanks to everybody who replied, both here and by mail. Several people
> pointed out that I said t_listen when I should have said t_bind - sorry,
> my fingers were running faster than my brain....
>
> However, nobody has answered the question that I was trying to ask. I can't
> have made a good job of the question :-)
>
> 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?

> Jeremy Harris jgh@root.co.uk

Well, I'm not an expert, but it would seem to me that moving into
the individual process wouldn't do much more than increase the amount of
work that has to be done. Right now the functionality is such that a
fixed number of pending connections may be queued up, on the grounds that
they will be quickly handled by the application (normally by forking a
child to do the work). However, once the queue is exhausted, the system
must refuse the connection to any subsequent clients. If the queue were
being handled in the process area, the operating system would have to

        A) do more work to decide the state of the socket in the process
        B) have additional protocol between the kernel and process to back
                up into the kernel in order to create the new socket for
                the process through the accept() call
        and,
        C) have some method to back up into the kernel whenever the queue
                filled, so that the refusal could be sent to the client

Seems like a whole lot more work for the kernel than just queueing pending
connection requests.

Joel A. Mussman
CONTEL Federal Systems



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:14 GMT