From: scott@tdc.rtp.dg.com (John Scott)
Subject: TLI t_accept behavior (was TLI: t_accept returns TLOOK (why?))
Date: Fri, 18 Dec 92 17:13:08 GMT
Organization: Data General Corporation, Research Triangle Park, NC

In article <1992Dec17.080226.3572@eab.retix.com>, erik@eab.retix.com (Erik Forsberg) writes:
|> In article <1gnhqsINN1d2@transfer.stratus.com> wendy@sw.stratus.com (Wendy McNaughton) writes:
|> >> In article <1992Dec2.215556.25482@bnrmtl.bnr.ca> kenneth@bnr.ca (Ken Rosenfeld) writes:
|> >> >I'm writing a server using the TLI library for TCP
|> >> >(on a Sun).
|> >> >
|> >> >The server executes the following in a loop:
|> >> >
|> >> >  t_listen(listenfd, ...)        /* receive connect indication */
|> >> >    
|> >> >  t_accept(listenfd, newfd, ...) /* accept the call */
|> >> >
|> >> >There is a case where this code does not work: Two clients
|> >> >make connect requests before the server executes the t_listen().
|> >> >The t_listen() then receives the first connect indication.
|> >> >The t_accept() fails, however, with t_errno = TLOOK.  
|> >> >A subsequent call to t_look() returns the T_LISTEN event.
|> >> >
|> >
|> >I ran into the same situation here with our SVR4-based UNIX (FTX).
|> >Our RPC implementation always assumes that if t_accept() fails
|> >with t_errno = TLOOK, it is as a result of a disconnect (and therefore
|> >calls t_rcvdis).  As Mat Cucuzella pointed out, this is consistent with
|> >the examples in Stevens' UNIX Network Programming book.  I also found
|> >similar examples in the AT&T SVR4 manuals.  
|> >
|> >The consensus here seemed to be that this is incorrect behaviour for
|> >t_accept.  It seems silly to interrupt one connection establishment
|> >just to process another.  Since we have access to the sources, we were 
|> >thinking of modifying our TLI library such that the t_accept call will 
|> >not be interrupted by another connection request.  This seems to work 
|> >well but was wondering if this is the proper thing to do. 
|> >
|> 
|> The MOST proper thing to do is changing TPI implementations to always
|> returning a qlen of 1 to the TLI library on the T_BIND_ACK response
|> message but internally queue up incoming connect indication upto
|> whatever limit you feel like (the original qlen may be a good number).
|> 
|> This avoids that not so cleverly written TLI applications still work
|> even if they get several connect indications at the same time and still
|> being able to handle this.
|> 
|> To simplify what I just said, the net effect is that the TPI Streams
|> driver itself queues many incoming connect indications, but they are
|> presented one at a time to the TLI user. That way the t_look() error
|> will never happen (unless it REALLY IS a disconnect indication).

That will work for most TLI clients.  Unfortunately, SVVS is not like most
TLI clients and could score the TPI provider as non-compliant (that is if
USL ever got around to writing a provider test that wasn't full of false
assumptions).

|> 
|> All Retix TPI Streams driver operates that way.
|> 
|> 
|> -- 
|> ---------------------------------------------------------------------------
|> Erik Forsberg, erik@eab.retix.com Phone: (310) 476-7133 FAX: (310) 476-7657

--
+------------------------------------------------------------------+
| John A. Scott                       | Phone: +1 919 248 5995     |
| Data General                        | Email: scott@dg-rtp.dg.com |
| 62 TW Alexander Drive               |                            |
| Research Triangle Park, NC 27709    |                            |
+------------------------------------------------------------------+
                                                       

Newsgroups: comp.protocols.tcp-ip