timon@sco.COM (timon) (06/30/88)
a puzzle for the net:
AT+T chose not to define an addressing scheme for their
TLI library. Instead they require the user program to pass
to the transport a pointer to an undefined address structure.
This requires that the user program know what address structure
the transport is expecting, and therefore makes each user
program transport specific.
This seems to make their interface completely unportable. They
claim to have designed TLI to allow application programs to be
completely independent of the transport. I don't see how this
can work if each and every user program must have hard-coded
dependencies based on a particular transport's addressing scheme.
- Why did they fall short here (aside from being lazy)?
- Is at+t working on a standard for this? Is any other group/vender?
- Are standards/conventions emerging for particular transports
(tcp/ip, osi tp4, netbios)?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Timon Sloane
The Santa Cruz Operation timon@sco.com
{uunet | decvax!microsof}!sco!timon
(408) 458-1422dannyb@kulcs.uucp (Danny Backx) (07/01/88)
In article <297@scolex> timon@sco.COM (timon) writes: > > a puzzle for the net: > >AT+T chose not to define an addressing scheme for their >TLI library. Instead they require the user program to pass >to the transport a pointer to an undefined address structure. >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. So, in summary : apart from TLI, only the name server should know about address structures. -- Danny -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Danny Backx | mail: Katholieke Universiteit Leuven Tel: +32 16 200656 x 3544 | Dept. Computer Science E-mail: dannyb@kulcs.UUCP | Celestijnenlaan 200 A ... mcvax!prlb2!kulcs!dannyb | B-3030 Leuven dannyb@blekul60.BITNET | Belgium
rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/02/88)
in article <297@scolex>, timon@sco.COM (timon) says: > > > a puzzle for the net: > > AT+T chose not to define an addressing scheme for their > TLI library. Instead they require the user program to pass > to the transport a pointer to an undefined address structure. > This requires that the user program know what address structure > the transport is expecting, and therefore makes each user > program transport specific. I think you missed something, as I did. The "address" structure in question is a standard "netbuf" structure. To write a transport non-spesific program you must do one extra step, but this is no big deal; to whit: When you issue "t_open" on the provider, you will receive a set of "default" options for the provider, among these are the maximum size, in characters, of an address and the maximum sizes of the various data types. These will dictate your address et al. It is important to remember that the "addresses" refered to by this are the _names_ assigned to the endpoint in question and _not_ the physical address/serial_number of the board, to whit: the address may be associated with different hardware at different times. As such addresses are arbitrary character strings, usually numonic, with several "suggested guidleines" for safe naming. The transport provider bears the burden of translating this into a media-dependant address, and as such this is not the problem of your software. The media-address may also be retreived through one call (I forget which...) Because the options related to data-packet size et al are prone to change after connection ("negotiable pramaters") to be transport independant you should issue t_getinfo and adjust your sizes accordingly. This is _IMPORTANT_ when you are using a hetrogenous machine types on the same transport, or when you are bridging between network types. t_getinfo returns the "smalest restricted maximums" and therefore prevents misshaps. Like dialing a phone, the actual address you use depends on what you want to reach, and therefore the user has to know something about what is expected, but the lower-level group and sub-group or serial-number issues are not really a valid issue when you are writing the application. If you are writing a driver, great things can be done for you by aquiring the network programmers guide (marginally helpful) and an "unpublished" refrence you can get free with your source code licence or by request (don't know how much) which I call the magic book, and they _sometimes_ call the "porting rules" though this is exactly what they are not, this doccument is teh one which actually gets around to telling you things you need to know but are only hinted at in the other documentation. "Conssume... enjoy... Tomorrow is for the testing..." Rob.
guy@gorodish.Sun.COM (Guy Harris) (07/02/88)
> It is important to remember that the "addresses" refered to by > this are the _names_ assigned to the endpoint in question and > _not_ the physical address/serial_number of the board, to whit: > the address may be associated with different hardware at different > times. As such addresses are arbitrary character strings, usually > numonic, with several "suggested guidleines" for safe naming. Guess again. Check out the manual page for "t_connect": In "sndcall", "addr" specifies the protocol address of the destination transport user, ... Protocol addresses are generally NOT names and are generally NOT mnemonic; if I want to know that "seismo.css.gov" is 192.12.141.25, I have to look it up. "seismo.css.gov" is the name of the machine; its protocol address in the Internet protocol family is the byte string represented in printed form as 192.12.141.25. (The byte string itself would probably contain 4 bytes with the decimal values 192, 12, 141, and 25.) The fact that the address is referred to by a "char *" does not mean it is necessarily a string of printable characters; it's just a string of bytes ("char" means several things in C, including "byte"). There may well be protocols in which the protocol address is some form of name that a human can deal with without too much pain, but neither the Internet transport/network protocols nor the ISO transport/network protocols have addresses of that form. Translating "user-friendly" names to protocol addresses is generally the responsibility of some layer of software other than the transport-layer or network-layer protocol implementation. Some protocol families have protocols for doing this; the Internet protocol family has the domain name server protocol, which is implemented atop transport-layer protocols (TCP or UDP). Other mechanisms can be used, such as searching a file (the "host table") or making queries to other sorts of name servers (e.g., a Yellow Pages server). Presumably, if one had, say a procedure that took a host name, a service name, and a protocols family name, and returned the appropriate byte string for the address of that service on that host in that protocol family, one could write a transport-independent program to access that service, assuming the service ran atop several transport layers and didn't depend on particular features of specific transports.
mre@beatnix.UUCP (Mike Eisler) (07/06/88)
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
rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/09/88)
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.
mark@cbnews.ATT.COM (Mark Horton) (07/15/88)
In article <1084@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >It is important to remember that the "addresses" refered to by >this are the _names_ assigned to the endpoint in question and >_not_ the physical address/serial_number of the board, to whit: >the address may be associated with different hardware at different >times. As such addresses are arbitrary character strings, usually >numonic, with several "suggested guidleines" for safe naming. >The transport provider bears the burden of translating this >into a media-dependant address, and as such this is not the >problem of your software. The media-address may also be retreived >through one call (I forget which...) I've used TLI too. What are you describing above? I once did a port of a working TCP/IP/socket application (built around the Wollongong WIN/3B2 1.1 distribution) to TCP/IP/TLI (WIN 2.0.) I found that I had to pass a struct sockaddr_in to t_bind, and I had to build the struct myself using gethostbyname, getservbyname, and the like. It seemed like TLI only replaced the bottom half of the socket interface, all the addressing stuff was still socket specific, which means none of it would work for TLI on some other transport. In general, for clients and servers, you have to specify not only the remote host address, but also the port name/number. Determining both of these quantities is going to be transport specific. For example, to write a generic TLI "remote login" application ala cu, for TCP/IP I have to somehow tell it to use the TELNET port, #25 (unless I want to use rlogin or supdup or something else.) For Datakit, I have to get the default port, whose name I think is "login". For OSI it will no doubt be something else. And of course these applications all have different protocols in the session, presentation, and application layer. Mark
mre@beatnix.UUCP (Mike Eisler) (07/15/88)
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
rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/23/88)
in article <843@elxsi.UUCP>, mre@beatnix.UUCP (Mike Eisler) says: > Xref: nusdhub comp.dcom.lans:365 comp.protocols.tcp-ip:1120 comp.protocols.iso:49 >>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, I don't know if you read teh entire thread, but your last comment is _EXACTLY_ my point in making the telephone analogy. The whole PURPOSE behind TLI is that you *should* pass any address you want to use to TLI as a string; and the TLI driver for whatever the network is, should do all the work of figuring out how the provider needs the address (in binary) and changing the string to binary. I don't know why you jumped off on the RFS tangent; who cares about RFS per se, it was the addressing that was at issue... The diference between "255.255.255.255" (the string) and 0FFFFFFFFx (four bytes of binary) is quite essential and obvious. The difference between "nusdhub.serve" and the six byte 802.3 serial number/address of this mahine (which I don't remember, and don't care about because I have and use TLI) is even more obvious and reasonable. One can be included in the UUCP support files, prompted for as input, supplied as a command argument, and passed around in a non-ambigous format (between human people); the other can not. TLI is intended to use string addresses, and applications which _only_ pass/accept memory structures are simply broken. If you look back through thi thread, you will find that all of this was started when one individual stated that it was stupid that AT&T didn't invent a universal address structure and build it into TLI. They did, they call it the string buffer; you know a length and an offset, also known as a netbuf structure to the TLI library. The thread was further complicated when this same individual lamented the fact that he couldn't implement *all* of TCP/IP _over_ TLI. Even attempting to implement TCP/IP _over_ TLI is stupid. The Whole point of TLI is to *dispose* of as many of the internal issues of things like TCP/IP, in order to create a more simple and basic programmer interface for the programmer who dosn't want to specialize in networking. Implementing TLI _over_ some or all of a TCP/IP transport provider makes sense, but trying to do it the other way around is dumb. Remember the "more-restrictive-shell-above-lesser-restrictive-environment" rule of systems design and arcitecture? Rob.