Xref: utzoo comp.dcom.lans:1614 comp.protocols.tcp-ip:4191 comp.protocols.iso:127
Path: utzoo!attcan!uunet!husc6!bloom-beacon!mit-eddie!ll-xn!ames!oliveb!sun!gorodish!guy
From: guy@gorodish.Sun.COM (Guy Harris)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses)
Message-ID: <61066@sun.uucp>
Date: 22 Jul 88 21:01:38 GMT
References: <60781@sun.uucp> <1110@nusdhub.UUCP>
Sender: news@sun.uucp
Lines: 65

> The fact that all you have ever seen of TCP/IP drivers written as
> TLI conformant functions pass the four byte addresses as actual
> bytes instead of a string like "109.90.42.6" is simply sad.

Excuse me, but this is nonsense; the difference between "actual bytes" and
"109.90.42.6" is trivial relative to the difference between "sun.com" and
"10.7.0.2".  If TLI forced me to pass a string like "109.90.42.6" to it, that
would be every bit as sad as if it forced me to pass that address down in
binary form.

> In essence this breaks the aledged uniformity.  To implement the
> TCP/IP and TLI over the same media,

You don't "implement TLI over a medium".  TLI/TPI is, in effect, an *interface*
that "transport providers" implement.  You implement a "TLI/TPI-conformant TCP"
or a "TLI/TPI-conformant UDP" or a "TLI/TPI-conformant ISO TP4" or a "TLI-TPI
conformant XNS SPP" or....

> the primitive kernel driver should be TCP/IP, and then a streams module
> which can convert TLI requests into TCP/IP should be written.

No, you implement a driver that provides the TCP or UDP protocol and that
conforms to the requirements of TPI and TLI.  That driver is what "converts
TPI/TLI requests into TCP".

> TCP/IP _is more_ complex, and therefore, to implement both TLI should be an
> optional addition onto the TCP/IP.

TCP and TLI are completely different types of things, so it's hard to say one
is "more complex" than the other, except to say "TLI supports functions TCP
doesn't provide" (which is true) or "TCP provides functions TLI doesn't
support" (which is also true).

> Then you place 109.90.42.6 in your Systems file;

I refuse to put something as gross as "109.90.42.6" into any configuration file
for a network utility; if I can't put the *name* of the machine there, that's
unacceptable.  There are, I believe, many *thousands* of hosts on the DARPA
Internet; I know there are thousands of hosts on Sun's network.  Sometimes
hosts may change their addresses but not their names.  Administering a network
of that size by using addresses rather than names would simply be impractical.

> The simple task of converting the string to the 4-byte couplet
> is not beyond the scope of a STREAMS module,

No, but it's not very useful, either.  What you *really* want is a mechanism
that can convert what you might call a "service specification" (i.e., "UUCP on
host 'sun.com' over TCP") into an address in whatever form the protocol
requires.  UUCP (which, I infer from your mention of a "Systems" file, is the
service to which you're referring here) would then ask for that service, and
hand *that* to TLI.


> All of this is much the purpose of the "adm" program which assembles
> the STREAMS modules which eventually make /dev/starlan operate
> the STARLAN product.  I would assume the correct "adm" program
> for an ethernet and/or internet support would activate two STREAMS
> multiplexers like /dev/ether.tcp and /dev/ether.tli or some such.

Are you actually familiar with TCP or IP, or is your only TLI/TPI experience
with, e.g., STARLAN?  If you haven't worked with TCP, you should probably study
up on it first, and preferably on TLI-conformant TCP implementations, so you
can discuss implementations of things other than STARLAN meaningfully, and
support for multiple protocols in general, meaningfully.  If all you know is
STARLAN, you're unlikely to know what's involved in protocol independence....