Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.dcom,net.lan,net.unix-wizards
Subject: Re: Networking on UNIX - 3 approaches
Message-ID: <6316@sun.uucp>
Date: Tue, 19-Aug-86 07:19:27 EDT
Article-I.D.: sun.6316
Posted: Tue Aug 19 07:19:27 1986
Date-Received: Wed, 20-Aug-86 08:32:51 EDT
References: <964@hoptoad.uucp> <3535@amdahl.UUCP> <1019@hoptoad.uucp>
Organization: Sun Microsystems, Inc.
Lines: 24
Xref: mnetor net.dcom:1218 net.lan:935 net.unix-wizards:7603

> This doesn't change the fact that I think the transport layer interface
> is very bad.  It defines new protocols, which are the last thing we need,
> and does so informally, which we should all have been scared away from by
> uucp.

Do you mean new protocols for communication between "service providers" on
different machines, or new protocols for communication between protocol
layers in a stream?

> Finally, it is limited to SV.3 to SV.3 connection.

How so?  Presumably, a program using the TLI library can do a "t_open" to
get a handle on, say, the TCP module, and then do a "t_connect" to connect
to a given Internet address and port number.  At this point, the descriptor
can be used to send data to, and receive data from, the service
corresponding to that port number on the host corresponding to that address,
regardless of what OS that host is running.  Some particular protocol
implementations may be poorly done, so that they assume that the other
implementation is "just like them", but I don't see how the TLI kernel-level
or user-level interface precludes doing it right.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)