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