NetNews Usenet Archive 1992 #30/NN_1992_30.iso/spool/comp/protocol/tcpip/5663

Text File | 1992-12-17 | 2.9 KB | 64 lines

Newsgroups: comp.protocols.tcp-ip
Path: sparky!uunet!retix.com!eab!erik
From: [e-mail] (Erik Forsberg)
Subject: Re: TLI: t_accept returns TLOOK (why?)
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Retix, Santa Monica CA
Date: Thu, 17 Dec 1992 08:02:26 GMT
Message-ID: <[e-mail]>
Lines: 53

In article <[e-mail]> [e-mail] (Wendy McNaughton) writes:
>> In article <[e-mail]> [e-mail] (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).

All Retix TPI Streams driver operates that way.


--
---------------------------------------------------------------------------
Erik Forsberg, [e-mail] Phone: [phone] FAX: [phone]