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

Text File | 1992-12-21 | 3.9 KB | 82 lines

Newsgroups: comp.protocols.tcp-ip
Path: sparky!uunet!psinntp!dg-rtp!tdc!scott
From: [e-mail] (John Scott)
Subject: TLI t_accept behavior (was TLI: t_accept returns TLOOK (why?))
Message-ID: <[e-mail]>
Sender: scott@tdc (John Scott)
Date: Fri, 18 Dec 92 17:13:08 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Data General Corporation, Research Triangle Park, NC
Lines: 70

In article <[e-mail]>, [e-mail] (Erik Forsberg) writes:
|> 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).

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, [e-mail] Phone: [phone] FAX: [phone]

--
+------------------------------------------------------------------+
| John A. Scott                       | Phone: [phone]     |
| Data General                        | Email: [e-mail] |
| 62 TW Alexander Drive               |                            |
| Research Triangle Park, NC 27709    |                            |
+------------------------------------------------------------------+