Xref: utzoo comp.dcom.lans:1559 comp.protocols.tcp-ip:4040 comp.protocols.iso:114
Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!decwrl!sun!aeras!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
Keywords: TLI transport independence
Message-ID: <836@elxsi.UUCP>
Date: 5 Jul 88 23:51:19 GMT
References: <297@scolex> <118@icarus.kulcs.uucp>
Sender: news@elxsi.UUCP
Reply-To: mre@beatnix.UUCP (Mike Eisler)
Organization: ELXSI Super Computers, San Jose
Lines: 48

In article <118@icarus.kulcs.uucp> dannyb@kulcs.UUCP (Danny Backx) writes:
>In article <297@scolex> timon@sco.COM (timon) writes:
>>This requires that the user program know what address structure
>>the transport is expecting, and therefore makes each user
>>program transport specific.
>
>I don't think what you describe is a BAD thing, I think it is a good thing !
>Suppose they had defined an addressing scheme in their TLI. In that case you
>could only work with that addressing scheme.
>
>What they do now isn't really transport specific. Your programs shouldn't be
>using adresses. They should use host names, and transform these host names
>into addresses using (e.g.) calls to a name server. These calls provide you
>with something, and you can pass a pointer to that something to TLI.

Designing a name server to serve two or more network processes using
the same transport protocol, but a different transport address scheme is
hard. For example RFS from AT&T relies on a name server that will run
on top of any TLI-based transport. When the name server is brought up,
it reads a file containing host names and TLI addresses in ASCII-hex
format. An RFS client must contact the RFS name server to get the address of an
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.

Obviously you can work around this by:
	- by not using a name server and instead supply addresses at mount
		(connection) time
		+ but you lose the nicety of a central name server

	- complicating the name server so that each server has
		multiple addresses. When a client contacts the name
		server, it could switch on the address of the client to
		match it to the correct version of the server address.

Life would have been simpler had AT&T defined addressing formats for
*each* the commonly used protocol suites (DoD/IP, OSI, XNS, DEC NET,
SNA, etc.), as well as establishing a registration service.

I would have also preferred that the TLI address be expanded from the
current opaque one-tuple to an opaque two-tuple. The first field would
be the address of "where" the peer is, and the second field would have
been the address of "what" the peer is. For example, this would make
implementing Sun's NFS over TLI easier, where you have to contact three
services (the "whats": PORTMAP, MOUNT, NFS) on the same host (the
"place") to establish an NFS "circuit."

	-mre