Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!ut-sally!husc6!bu-cs!m2c!applix!mark
From: mark@applix.UUCP (Mark Fox)
Newsgroups: comp.protocols.tcp-ip
Subject: Re: STREAM, TLI, and (of all things) MAP 3.0
Message-ID: <566@applix.UUCP>
Date: Fri, 31-Jul-87 10:21:22 EDT
Article-I.D.: applix.566
Posted: Fri Jul 31 10:21:22 1987
Date-Received: Sun, 2-Aug-87 00:45:06 EDT
References: <8707310111.AA28460@ucbvax.Berkeley.EDU>
Reply-To: mark@applix.UUCP (Mark Fox)
Organization: APPLiX Inc., Westboro MA
Lines: 66

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