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.