Path: utzoo!attcan!uunet!mcvax!ukc!stc!root44!jgh
From: jgh@root.co.uk (Jeremy G Harris)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Call queueing
Summary: Why this function in the kernel?
Keywords: tcp listen kernel
Message-ID: <628@root44.co.uk>
Date: 2 Sep 88 15:27:38 GMT
References: <8808291548.AA14752@violet.ICO.ISC.COM>
Reply-To: jgh@root44.UUCP (Jeremy G Harris)
Organization: UniSoft Ltd, London, England
Lines: 24

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?

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?

Opinions, anybody?

Jeremy
-- 
Jeremy Harris			jgh@root.co.uk