Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!unisoft!hoptoad!gnu
From: gnu@hoptoad.uucp (John Gilmore)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: In this corner -- sockets!   In that corner -- TLI & streams!
Message-ID: <3373@hoptoad.uucp>
Date: Mon, 23-Nov-87 01:51:58 EST
Article-I.D.: hoptoad.3373
Posted: Mon Nov 23 01:51:58 1987
Date-Received: Wed, 25-Nov-87 20:34:08 EST
References: <283548.871111.PAP4@AI.AI.MIT.EDU> <302@halley.UUCP>
Organization: Nebula Consultants in San Francisco
Lines: 48

Throughout the discussion of sockets -vs- TLI, I am getting the persistent
impression that the TLI people think sockets are somehow "TCP/IP specific"
while TLI is "general".

Berkeley sockets are in regular use with at least three major protocol
suites (TCP/IP, Unix domain, and XNS).

I can't say that there are no dependencies, but the major ones are gone.
Note that 4.3BSD sockets were slightly more general than 4.2BSD's, since
XNS had been ported to the system in between.

Another posting said that TLI allows both byte-stream and message-oriented
protocols, implying that this was a feature sockets lack.  It ain't so --
sockets can do it too.

I don't know the difference between streams and TLI, though someone
said they are independent, but here's my uneducated complaints about both:

* TLI only exists because of AT&T's "Not Invented Here" attitude, and I
hate to help people who do that.

* The "select" or "poll" call is essential in providing easy, low overhead
access to several network connections or devices or files.  For
example, in a telnet (remote login) program, the program should wait
until either a new packet of data comes in, or until a key is hit.
Select was implemented throughout the system -- it works on any kind of
file descriptor.  "Poll" only works on streams, not on pipes, files, or
devices like serial ports, requiring ugly kludges for simple stuff like
telnet.  And they could have called it "select" since it does the same
thing, but NIH reared its ugly head again.

* I have heard that the multiple protocol levels in a streams implementation
require copying of the data many times as it passes up and down the stream
stack.  (Dennis Ritchie's original streams for V8 unix didn't do that, but
the Sys V folks reimplemented it and botched it.)

For me the choice is clear.  There's a bunch of public domain software
out that uses the socket interface, and while I could waste my time rewriting
it so AT&T can play NIH, why bother?

For you-all, I don't know if the choice is clear.  Best would be to 
consult somebody smart who has worked with both.  I know Guy Harris (sun!guy)
has done some work with streams; if he can't intelligently contrast
streams/TLI versus sockets, he probably knows who can.
-- 
{pyramid,ptsfa,amdahl,sun,ihnp4}!hoptoad!gnu			  gnu@toad.com
Love your country but never trust its government.
		      -- from a hand-painted road sign in central Pennsylvania