Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!purdue!decwrl!ucbvax!violet.ICO.ISC.COM!dougm
From: dougm@violet.ICO.ISC.COM ("Doug McCallum")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: Call queueing
Message-ID: <8808291548.AA14752@violet.ICO.ISC.COM>
Date: 29 Aug 88 15:48:02 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 28

In reply to your message of 25 Aug 88 16:10:01 GMT
-------
> 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?

The reason you want to allow for queueing of incoming connection requests is
that you want to buffer them while an application is processing a previous
one.  The alternative is to reject the connections until the application is
ready again.  Even with minimal overhead tin getting the appliation started
there will be cases where multiple connection requests arrive back-to-back
from the network.  You don't want to reject these so you queue them until
there is time to properly respond.

In the BSD systems, the queued connection requests get accepted
automatically.  In the TLI mechanism, it is possible that the connection
request has not been responded to giving the application final say on
whether to accept or reject the request.

One minor clarification, the TLI indication to queue connection requests is
in the t_bind call and not the t_listen.  T_listen is not the same as the
socket listen.  t_listen waits for an incoming connection request and
returns that to the application.  The information in the connection request
is then given to the t_accept call if the connection is to be accepted or
the t_snddis call if the connection is to be rejected.