Xref: utzoo comp.dcom.lans:1566 comp.protocols.tcp-ip:4053 comp.protocols.iso:116
Path: utzoo!attcan!uunet!seismo!esosun!ucsdhub!jack!nusdhub!rwhite
From: rwhite@nusdhub.UUCP (Robert C. White Jr.)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TLI transport specific addresses
Message-ID: <1096@nusdhub.UUCP>
Date: 8 Jul 88 23:08:16 GMT
References: <836@elxsi.UUCP>
Organization: National University, San Diego
Lines: 44

in article <836@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says:
> Xref: nusdhub comp.dcom.lans:310 comp.protocols.tcp-ip:951 comp.protocols.iso:39
> RFS server. Well, what if an RFS client and RFS server both support TCP/IP,
> but different implementations (eg. Lachman and Wollongong) with different
> address formats? The address of the file server will be incompatible with
> the client's TCP/IP implementation.

Well, if this is the case, or even if it's not, every protocol
suit served by the "listener" (part of the TLI et. al.) possesses
a unique "service code" which uniquely identifies that service
on that protocol.  When the requests come throught the listener
they are sorted out by code, protocol (i.e. TLI driver), and address.

The address formats (primitive) are handled by the kernel driver
(if it wernt, the TLI would never _get_ the message) and the
address names (user-level) are passed, designated, and controled
by the systems-adminstrators, and as such can be and are "character
strings" in free form.

When you spesify an address like 255.255.255.255 (for instance) the
TLI library passes a "request for translation" down to the driver.
For TCP/IP (I thing) this would become two couplets of byte values;
to whit: FF FF FF FF.  For STARLAN they would either be returned as
the character string (unaltered) or an 802.3 tri-couplet (6 byte)
address, I dont remember which.  More or less at this point you don't
ever touch this address again.

You (the application) don't need to know the addressing format for
your provider any more than you need to know the sixteen tones
used in DTMF dialing to use a Touch-Tone(r) phone.  You provide
the free-form address as a string, and the rest of the system does
it's best to make the connection you want, but like the PSTN
(Public Switched Telephone Network) if you don't know the number
you want, you probably arn't gonna get through!

By providing it as a "string" of ascii characters, the user and
programmer dosn't have to know if the provider is expecting
a string, binary, hex, or whatever, the TLI driver for that
device _HAS_ to know that, so the two workout the difference
without you having to get your hands dirty.  N'cest pa?

(besides how else than as a string are you going to generate 0.0.0.0 ?)

Rob.