Xref: utzoo comp.dcom.lans:1600 comp.protocols.tcp-ip:4166 comp.protocols.iso:123
Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!pasteur!ucbvax!decwrl!pyramid!prls!mips!wyse!vsi1!altnet!altos86!elxsi!beatnix!mre
From: mre@beatnix.UUCP (Mike Eisler)
Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso
Subject: Re: TLI transport specific addresses
Message-ID: <843@elxsi.UUCP>
Date: 14 Jul 88 20:07:53 GMT
References: <836@elxsi.UUCP> <1096@nusdhub.UUCP>
Sender: news@elxsi.UUCP
Reply-To: mre@beatnix.UUCP (Mike Eisler)
Organization: ELXSI Super Computers, San Jose
Lines: 83

In article <1096@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes:
>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.
>
>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.

RFS gives you the choice of specifying an ASCII string that is passed
directly to TLI unaltered, or a string of hexadicamal digits preceded
by \x.  RFS will convert each pair of digits to an ASCII byte,
construct the byte string, and pass it to TLI.  You do NOT specify 4
byte addresses in  "IP dot" format (255.255.255.255).  First of all,
RFS doesn't "dot" format. Second, they are inadequate.  The address of
a service in the TCP/IP world requires the network/host number (4
bytes), and the port number (2 bytes), both in network byte order. Thus
what you encode for RFS and pass to TLI is a string of bytes that at a
minimum contains the aforementioned 6 bytes. However, neither TLI nor
RFS define how these bytes are laid out for TCP/IP, though AT&T has
defined a format for Starlan.  It is up to the implementor of the
protocol (eg. Lachman or Wollongong implementing TCP/IP), define how he
wants the bytes of the address laid out for t_bind() and t_connect()
calls.

Well, there are already two obvious ways an implementor could lay them
out:
	h h h h p p 	or
	p p h h h h

Also:   h h p h h p . In other words, 6! = 720 permutations.  But wait,
there's nothing that says we can't have other bytes thrown in for good
measure. Look at the BSD sockaddr_in format. It is 16 bytes:  Bytes 1
and 2 are the family (AF_INET), 2 and 3 are the port
number (network order), 4,5,6,7 are the network/host number (network
order), and 8-16 are zeroes. This happens to be the format that Lachman
uses, presumably because it was the only defined way in lieu of AT&T
not defining one. Also, it makes it easier to implement sockets over
STREAMS.  I understand that the Wollongong format is similar Lachman's,
but different.  Any amount of difference will be enough to prevent the
use of a common name server for a network of RFS clients and servers
using different implementations of TCP/IP under TLI.

Let me prove this to you by example:
	svc	is the name of a RFS server running Lachman TCP
	clnt1	is the name of a RFS client running Wollongong TCP
	clnt2	is the name of a RFS client running Wollongong TCP

clnt2 contacts the name service for the address of svc to send a
mount request too. This works because the name server stores svc's
TCP/IP address in Lachman format, and so clnt2 can t_connect()
to that address.

clnt1 now wants to mount a resource of svc's as well. He contacts
the name server, and gets svc's address. He tries a t_connect()
and promptly gets an error, because the Wollongong TCP/IP
implementation can't understand an address in the format used by Lachman.

Note that this breaks even though the name server and the RFS clients
treat addresses as opaque objects.

>
>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!

Yeah, but regardless of whether I use rotary, or touch tone, and whether
the party I'm calling uses rotary or touch tone, we both agree on what
our phone numbers are, and what the order of the digits are. Because of
this, we can use a common name service called the telephone book.

	-Mike Eisler