Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!columbia!rutgers!labrea!aurora!ames!sdcsvax!ucbvax!violet.isc.COM!dougm
From: dougm@violet.isc.COM ("Doug McCallum")
Newsgroups: comp.protocols.tcp-ip
Subject: Re(2): STREAM, TLI, and (of all things) MAP 3.0
Message-ID: <8707312233.AA03919@violet.ISC.COM>
Date: Fri, 31-Jul-87 18:33:57 EDT
Article-I.D.: violet.8707312233.AA03919
Posted: Fri Jul 31 18:33:57 1987
Date-Received: Sun, 2-Aug-87 08:25:29 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Distribution: world
Organization: The ARPA Internet
Lines: 52

In reply to your message of 31 Jul 87 14:21:22 GMT
-------

 >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...

Actually, t_bind == (bind+listen)
	  (t_listen+t_accept) == accept
	  t_connect == connect
	  t_rcv/t_snd == read/write (or send/recv)
	  t_rcvudata/t_sndudata == recvfrom/sendto

The mappings aren't quite exact, but close enough.  With the names being so
similar, expecially t_listen and t_accept, it is easy to assume they work
the same way.

 >Did NIH have something to do with the design of TLI?

Probably a little NIH and a little of trying to generalize a little further.
There are some good ideas, too bad there are some bad ones as well.

 >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?

Almost.  Without doing some work with which modules are present in the
stream you might have some minor problems.  If you stay with SOCK_STREAM
type usage, you can do pretty well by having the socket emulation library
set the STREAM up to have the read/write interface once the connection is
established.  The SOCK_DGRAM type sockets would be more work since address
information won't be available if you do a read.  In fact the read will fail
if there is address information (in a control portion of a message) and you
haven't setup the read/write interface.  The recv*/send* emulation could
deal with it though.

The main problem is that while sockets preserve file descriptor semantics,
TLI doesn't.  You have to use TLI calls unless you make provisions to use
the read/write interface.  You can't have both at the same time.

 >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?

Nope.