AUERBACH@CSL.SRI.COM (Karl Auerbach) (07/31/87)
I was wondering whether TLI (Transport Level Interface) is an intrinsic part of STREAMS? If severable, is TLI required by AT&T? 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? If TLI is an ISO transport interface, who provides graceful close? (ISO transport does not have graceful close, that's part of session.) I have on my desk a copy of a working document from the GM MAP 3.x folks. It defines a programmatic interface for applications. If anyone is familiar with that and TLI, I'd like to hear your comments. --karl-- -------
mark@applix.UUCP (Mark Fox) (07/31/87)
In article <8707310111.AA28460@ucbvax.Berkeley.EDU> AUERBACH@CSL.SRI.COM (Karl Auerbach) writes: >... several questions follow... I just put down the UNIX System V manuals from AT&T and Prentice-Hall. I also have been looking at our Bell Technologies 386 running S5V3. Here is what I have observed: >I was wondering whether TLI (Transport Level Interface) is an intrinsic >part of STREAMS? If severable, is TLI required by AT&T? TLI is implemented by a library called libnsl_s.a in /usr/lib. It contains all of the t_ calls. TLI is implemented on top of STREAMS. Is it severable or required? Check the licensing agreements... >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? Both synchronous multiplexing using the poll (== select) call and asynchronous multiplexing with the I_SETSIG ioctl (== SIGIO) are supported in addition to a non-blocking option (by setting O_NDELAY) on most of the calls >If TLI is an ISO transport interface, who provides graceful close? (ISO >transport does not have graceful close, that's part of session.) The UNIX System V Network Programmer's Guide says that graceful close is an optional procedure. Does this mean that t_sndrel defaults to a t_snddis for ISO? >I have on my desk a copy of a working document from the GM MAP 3.x folks. >It defines a programmatic interface for applications. If anyone is familiar >with that and TLI, I'd like to hear your comments. MAP's programmatic interface, from my hazy recollection, is primarily at the CASE and directory service interfaces in the application layer. TLI is a transport layer interface. Now I have a question based on an observation: It seems that AT&T's TLI primitives are not very different from the Berkeley socket calls. For example: poll == select; t_open == socket; t_bind, t_accept, t_connect, t_listen == bind, accept, connect, listen; t_rcv, t_snd == recv/recvfrom, send/sendto; t_snddis == shutdown... Did NIH have something to do with the design of TLI? Actually the real question is: If I have an application that communicates with other processes using fairly vanilla socket calls, couldn't I just implement the socket calls for the System V port using TLI calls or at least encapsulate the Unix calls within my own primitives? Or am I missing some basic incompatibility? By vanilla I mean that I am not particularly interested in exploiting protocol options such as call user data or graceful close. Oh yes, another question: Are there any System V equivalents for the Berkeley Network library functions, such as gethostent and inet_addr, and files such as /etc/hosts and /etc/services? I found no mention in the Network Programmer's Guide or Release Notes. Do I have to pay extra for them? -- Mark Fox Applix Inc., 112 Turnpike Road, Westboro, MA 01581, (617) 870-0300 uucp: seismo!harvard!m2c!applix!mark
dougm@violet.isc.COM ("Doug McCallum") (07/31/87)
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.