Xref: utzoo comp.dcom.lans:1601 comp.protocols.tcp-ip:4167 comp.protocols.iso:124 Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ucsd!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: TCP/IP _over_ TLI???? (was: TLI transport specific addresses) Message-ID: <1110@nusdhub.UUCP> Date: 22 Jul 88 00:36:25 GMT References: <60781@sun.uucp> Organization: National University, San Diego Lines: 108 in article <60781@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) says: > Xref: nusdhub comp.dcom.lans:361 comp.protocols.tcp-ip:1113 comp.protocols.iso:47 > > "Alleged" is the correct word here. There's no uniform way of doing this > ASCII string to address translation in S5R3 as it is distributed. In fact, I > don't think there's any way to do that translation in S5R3 as it's distributed, > period. Here is a "for instance" where you are wrong. ALL starlan addressing uses the 802.3 six-byte couplet for addressing purposes. Further RFS gets "name service" for all the available resources, but not the machine names. When any TLI conformant application requests, including RFS, want to make a connection they pass a "name" e.g. "nusdhub.serve" to the TLI interface. somewhare below this, the TLI and or STARLAN driver groups fardle around and recover the machine address (802.3) and then establishes the connection. Even though the (admittedly three layers) receives the "name string" the addressing used after the address determination phase is the byte string. At no point does the "uucp" "cu" or RFS task enquire about the six byte string. The fact that all you have ever seen of TCP/IP drivers written as TLI conformant functions pass the four byte addresses as actual bytes instead of a string like "109.90.42.6" is simply sad. In essence this breaks the aledged uniformity. To implement the TCP/IP and TLI over the same media, the primitive kernel driver should be TCP/IP, and then a streams module which can convert TLI requests into TCP/IP should be written. TCP/IP _is more_ complex, and therefore, to implement both TLI should be an optional addition onto the TCP/IP. Then you place 109.90.42.6 in your Systems file; you spesify the TLI<->TCP/IP converter module as the first-push-in-the-list; and you spesify the cloning module for TCP/IP as the device. Bam, you are TLI conformant. The simple task of converting the string to the 4-byte couplet is not beyond the scope of a STREAMS module, and you have full function from bot modules. Similarly, you might write the drivers as two seperate tasks, and assemble a multiplexing stream on media initalization where both drivers drive the down-stream media as necessary, but respond to TLI or TCP/IP as necessary when working upstream. This _is_ what streams modules are for you know. To do TCP/IP _over_ TLI is simply stupid. >> The idea is (according to the manuals) to have a layer which >> accepts a single string/sequential structure from above >> and does to it what is necessary to the media/protocol below. >> Either the TLI layer is made sufficiently intellegent to take >> the input as a string, or the whole point of a uniform >> interface goes right out the window. > > OK, then, the whole point of a uniform interface just went out the window. TLI > does not take the input as a string in the TCP/IP implementations I know of. > What it takes is a *byte* string, containing the address in what is likely to > be a *binary* form (I had the impression that Datakit took human-readable > strings; could this be the source of some of the confusion?). As I said, doing TCP/IP _over_ TLI is stupid. They are *comprable* in form and purpose, and TLI _is_ designed to be more "elementary" than TCP/IP. Trying to squese TCP/IP through TLI is like hooking 100amp wire to a 15amp breaker; It is _NOT_ the way these things are supposed to be done. >> To whit: (from definition of M_PROTO message T_INFO_ACK of the >> TLI internals definition from the "porting rules" doccument) >> >> ADDR_size (a return value of) -2 spesifies that the transport >> provider does not provide user access to transport >> spesific addresses. >> >> T_ERROR_ACK Return coed TBADADDR: >> Indicates that _protocol_ address was in incorrect format >> or the address contained incorrect illegal information... >> >> These two imply (wrongly?) that the TLI is for insulation from the >> uglies, instead of the "this is just another library" outlook. > > No, you are *inferring* wrongly that the TLI insulates you from the uglies. An > address can be in "incorrect format" without that "format" having to be some > human-readable format. The address is in the form of a count and a byte > string, with the count specifying how many bytes are in the string. If you > pass a 1-byte address to TCP or UDP, it should reject it as being in an > incorrect format because TCP and UDP addresses are 6 bytes long (4 bytes of IP > address, 2 bytes of port number). The *purpose* of TLI _is_ to insulate you form the uglies; That is why things like uucp and cu have been re-written to be TLI conformant; so simple ASCII strings may be spesified in the ASCII files (Systems, Dialers, Dialcodes, Devices... remember them?) and allow these versions of uucp and cu to be used with any media (please no more corrections on my use of 'media,' this is the broad and general usage menaing 'whatever- is-necessary-below-this-point') Depending on what is required, you might need to set an address like "109.94.60.2:rlogin" to properly implement TLI through TCP/IP, or perhaps place something similar in the Dialers spec, but I don't really know because I have not expended any energy on the topic outside this conversation. All of this is much the purpose of the "adm" program which assembles the STREAMS modules which eventually make /dev/starlan operate the STARLAN product. I would assume the correct "adm" program for an ethernet and/or internet support would activate two STREAMS multiplexers like /dev/ether.tcp and /dev/ether.tli or some such. Rob.