🚀 go-pugleaf

In article <818@netwrx1.UUCP>, slaski@netwrx1.UUCP (Robert Slaski) writes:

> Why is this a problem?  The t_accept call will fail with a T_LOOK
> event if during the responder process initialization a new connect
> request has come in on the listening endpoint.  For lightly loaded
> hosts this is probably not a problem, for a heavily loaded host, 
> such as a DDN gateway, it is a problem.  No great solution is offered 
> - our implementation waits to give the tsap daemon a chance to
> recognize the new connection (i.e., call t_listen) and then try
> and do the t_accept again, eventually giving up and refusing the
> connection because of congestion.
> 

Essentially the trade-off in this matter is whether you want to catch all
the incoming requests or maintain the semantics of TConnResponse. 
Since I was doing performance tests I chose the former by doing the
t_accept within my TLI version of the daemon and then forking the service.
This works fine because session always accepts and does not send data
with TConnResponse, at least that was the case with ISODE 5.0.
So my version of TConnResponse is a dummy routine!

Keith Coulson
AT&T Bell Laboratories
Summit NJ