Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!rutgers!ucla-cs!zen!ucbvax!violet.isc.COM!dougm
From: dougm@violet.isc.COM ("Doug McCallum")
Newsgroups: comp.protocols.tcp-ip
Subject: Re: STREAM, TLI, and (of all things) MAP 3.0
Message-ID: <8707311744.AA02059@violet.ISC.COM>
Date: Fri, 31-Jul-87 13:44:35 EDT
Article-I.D.: violet.8707311744.AA02059
Posted: Fri Jul 31 13:44:35 1987
Date-Received: Sun, 2-Aug-87 03:08:32 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 45

In reply to your message of Thu 30 Jul 87 18:07:20-PDT
-------
 > I was wondering whether TLI (Transport Level Interface) is an intrinsic
 > part of STREAMS?  If severable, is TLI required by AT&T?

It is possible to have streams without TLI.  TLI is implemented as a STREAMS
module and library code.  TLI is the programmer interface to the Transport
Provider Interface which is the format of messages used to communicate with
a transport protocol module.  STREAMS by itself doesn't define message
format, just message type.

TLI is required to be implemented if the Network Extensions are supported.
It is possible to leave that out of the system.  You aren't required to use
TLI as a user, but if you don't have an alternate interface, its easier to
use TLI than to process all of the message formats yourself.

 > Can TLI support fully asynchronous operations.  In other words can
 > I initiate a bunch of connects, sends, listens, receives.., continue
 > running and get some sort of call-back, up-call, AST (pick your favorite
 > name) when something completes?

Yes.  When a t_bind is done, it includes a count of maximum pending connect
requests, similar to what listen does in the socket world.  The difference
being that with TLI, you can accept, connect or both on the stream.
Accepting a connection requires first listening for a connection request.
You can read in multiple connection requests and then decide which ones to
accept or reject.  Accepts can either be done on a new stream or on the same
stream you received the request on.

You can also elect to receive a signal when a stream has data at the stream
head.  To determine which stream has the data, the poll system call is used
in much the same way as select on a BSD system.  TLI (actually STREAMS) is
flexible enough that you can initiate several connections and not wait for
the results and then go back later to determine if they are done.
One thing to note, the poll call only works on STREAMS descriptors and not
on things like ttys.

 > If TLI is an ISO transport interface, who provides graceful close?  (ISO
 > transport does not have graceful close, that's part of session.)

TLI only provides a graceful close if the underlying transport provides it.
TLI is ISO in flavor, it is supposed to be general enough for other
protocols.  The calls are similar to the ISO service primitives.
Unfortunately, this has some problems for TCP, primarily in how to deal with
urgent data.  Urgent data is not the same thing as expedited data.