Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!ut-sally!im4u!esc-bb!halley!bc
From: bc@halley.UUCP (Bill Crews)
Newsgroups: comp.protocols.tcp-ip.ibmpc
Subject: Re: Berzerkeley sockets (and MS-DOG)
Message-ID: <302@halley.UUCP>
Date: Mon, 16-Nov-87 22:14:48 EST
Article-I.D.: halley.302
Posted: Mon Nov 16 22:14:48 1987
Date-Received: Thu, 19-Nov-87 06:50:08 EST
References: <283548.871111.PAP4@AI.AI.MIT.EDU> <8711111448.AA24644@clutx.clarkson.edu>
Reply-To: bc@halley.UUCP (Bill Crews)
Organization: Tandem Computers, Austin, TX
Lines: 39

A couple of people have asked me via e-mail what TLI is, after I suggested
that TLI might be a superior interface to *networks* than sockets or the
interface suggested by the TCP RFC.  First, TLI stands for Transport-Level
Interface.  This is essentially AT&T's answer to sockets and is the way
networking applications access Streams-based protocol stacks.

One reason it might be better is that it makes no assumptions about the
underlying protocols -- or, I should say, minimal assumptions.  For instance,
connection-oriented service, a "byte-stream" mode is supported.  Some
underlying protocols may allow preservation of message boundaries and some may
not.  The application programmer can maintain portability by refraining from
making that assumption.  Nothing in TLI forces that assumption.

I heard a shot taken recently at Streams.  I would be interested in hearing
what the complaint is, since the message-passing mechanism in Streams, among
other things, allows protocol layers to be really isolated.  This matters to
people who want their applications to run over TCP/IP or UDP/IP or TP4/IP
(different IP) or XNS/IDP (I think that's what it is called) and so on.

I would also be interested to hear if anyone has complaints about TLI's
provision for expedited data.

One significant point here is whether the software interface you are trying to
achieve is intended to be protocol-independent.  Although most networking
applications now use sockets, new and upgraded applications will be using TLI
as well.  Why not take advantage of this fact and the fact that, with TLI, one
also gets the protocol-independence one needs in these days of OSI, TCP/IP,
and XNS suites AND multiple protocol paths within each suite?

If you need a lower-level interface for speed for nonportable applications,
fine, but please provide also a protocol-independent transport mechanism.  I'm
trying to get protocol stack interoperability at levels 5 and 6 as well, but
am always drug back by problems at level 4.

-bc
-- 
Bill Crews                                   Tandem Computers
                                             Austin, Texas
..!rutgers!im4u!esc-bb!halley!bc             (512) 244-8350