Xref: utzoo comp.dcom.lans:1590 comp.protocols.tcp-ip:4129 comp.protocols.iso:120 Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!ico!dougm From: dougm@ico.ISC.COM (Doug McCallum) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses) Message-ID: <7324@ico.ISC.COM> Date: 16 Jul 88 19:09:32 GMT References: <666@cbnews.ATT.COM> <1104@nusdhub.UUCP> Reply-To: dougm@ico.UUCP (Doug McCallum) Organization: Interactive Systems Corp., Boulder CO Lines: 142 In article <1104@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >in article <666@cbnews.ATT.COM>, mark@cbnews.ATT.COM (Mark Horton) says: >> Xref: nusdhub comp.dcom.lans:345 comp.protocols.tcp-ip:1043 comp.protocols.iso:42 >> >> I've used TLI too. What are you describing above? > >I begin to think That I don't know enough about TCP/IP to fully understand >what you are exactly trying to accomplish, or its spesific problems/ >detils; but here goes... You have a few things slightly confused. I'll try to explain where in the text. >TLI is (as I deal with it any way) a basic way of providing description >and contlrol of (aledgedly) any transport media. It's purpose is to ... >device on the other end is listening for such data, and applications >will handle the details from there. I can agree with this. TLI provides a set of basic functions for establishing and maintaining "transport" connections. > >TCP/IP is a media protocol which involves addressing and connection >metenence. It is inteneded that other protocols would be implemented >_above_ some or all of TCP/IP. This is where you are wrong. Although the mapping of TCP/IP to the ISO Reference Model isn't perfect, TCP is basically a transport protocol. It is not a media protocol by any means. It provides all the reliability you assume the transport TLI wants will provide. > >If my perceptions are correct then trying to write a TCP/IP driver >over a "TLI device" is a non-sequetor. The order, top to bottom, >of the stream should be: TLI over TCP/IP over STREAMS Device; such >that you have a STREAMS conformant TCP/IP driver for your ethernet >board, and then you push a custom made TLI-to-TCP/IP STREAMS module >on the stream before you hand the connection to a TLI conformant >application. You wouldn't normally write a TCP/IP driver over a TLI device (but I can see a case where you might). All the previous discussion seemed to be saying that a TCP/IP device would support TLI directly. That is, it conforms to the AT&T "Transport Provider Interface" specification which the TLI library and modules expect. Since TCP can be implemented to the TPI specification, no special conversion module is required. > >Were you to put TCP/IP _above_ the TLI you would already have been >issued the sub device numbers, and already possess the connection >(in remote startup) or be insulated form same (originating a call) Huh? I missed something. When did TCP get moved above TLI. The discussion started out about addressing being a problem with TLI since it doesn't specify any particular format or even set down guidelines. In all of this, TCP was below TLI and TLI was being discussed as the way to write applications that would run over TCP/IP. > >The WHOLE POINT of the TLI is to remove the details of the connection >from the application. A TLI conformant program only needs know >two or three things; 1) an address in "plain english" (c.f. >something that a user could be prompted for at the keyboard); Nowhere in the TLI specification or documentation does it state this. In fact, in the "Network Programmer's Guide", the example given uses an "integer" and not something a user would normally want to enter in at a keyboard. I think you've missed the point of TLI or been biased by the one transport layer implementation you seem to have used. TLI provides a way for an application to establish transport layer connections. Addressing is specific to the transport protocol being used. >2) A service code (If and only if the address can provide more than >one service); and 3) the file-system name of a provider. In the sense you are referring to them (RFS and the listener service) service codes are specific to an "application" and not a transport. The application is the listener service. Other applications will work differently. >The TLI device is "opened" (cloned as necessary); the plain english >address is passented to the driver for translation; the driver This is not normally the case. Look at some of the other transport providers that AT&T uses. They don't all work this way. In any case, hostname to internal address translation wouldn't be done in the transport protocol and asking a user to enter a 12-digit hex number or a 32-digit hex number isn't what I would call plain english. >translates this to an address which will be useful to the rest ... >To implement rlogin under TLI you would simply do the following: >write rlog-serve shuch that: ... >write rlogin such that: ... >Add rlog-serve to the listener database on every machine which >will accept rlogin requests (you need to know the serviec code >to do this.) while you are doing this you record in the database >that the listener should i_push the read()/write() module on >the stream before starting rlog-serve. And it wouldn't work with systems that weren't based on TLI. Other systems won't implement the listener service. The listener service is a session layer specific to some of AT&T's applications. The rest of the world doesn't work that way and the rest of the world's applications outnumber the few AT&T applications. >If you want TCP/IP and TLI stuff on the same media, you would make >a TCP/IP STREAMS deiver for the media. The program which oversees Now you are confusing TLI with the transport itself. Using TLI as a program interface should not and must not get in the way of using the transport protocol. Once you get on the media, TLI is totally irrelevant. If it isn't, someone did something wrong. >the TCP/IP workings establishes a TCP/IP address for the TLI ... >(deeper) end of the module. It would also seem that this >'other' protocol could be anything! (X.25; TCP/IP; STARLAN; >whatever). > >(Or maby not, considering I don't really know the innards >of TCP/IP. It may also end up that TCP is on the same >level as TLI and that IP may be below both of them equally. >Or TCP and TLI may be available over any media and things >like TCP/STARLAN and TLI/IP may be possible????????????? TCP is basically a transport. IP is basically a network layer. TLI is neither - it is a program interface for a tranport layer. The issue that you missed is that TLI doesn't specify how addresses for a specific transport should look. Actually, TLI shouldn't do this, there should be an address format registry that says how to format addresses for a specific transport. You should also be aware that Starlan is the media in you examples. There is a transport protocol called URP sitting above the media dependent part. Sorry to be so verbose, but the article prompted a comment since it was so confused.