jam@RADC-LONEX.ARPA (09/09/88)
> 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