Xref: utzoo comp.dcom.lans:1584 comp.protocols.tcp-ip:4102 comp.protocols.iso:119 Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!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: <1104@nusdhub.UUCP> Date: 15 Jul 88 22:54:02 GMT References: <666@cbnews.ATT.COM> Organization: National University, San Diego Lines: 127 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... 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 make a through-the-media pipeline through which data may be passed with total reliability (Session/Virtual circut) or of providing a method of asserting data on a media with the implicit intent that the device on the other end is listening for such data, and applications will handle the details from there. 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. 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. For instance, with STARLAN on a 3B2 there is the program "pumped" onto the board, two kernel drivers (NAU and SRM) the 'adm' program which assembles the STREAM durring startup, hands a hook to the 'listener' and then goes deamon. 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) 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); 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. The TLI device is "opened" (cloned as necessary); the plain english address is passented to the driver for translation; the driver translates this to an address which will be useful to the rest of the process (whatever that might be!) and returns a pointer to same if necessary; the user submits a "bind" request by passing the dirver the above address and the service code (and optional init data if necessary) and is returned "success" or "failure" code dependant on wethaer the conection went through (etc.). After successful compleetion of the connect, the user only has to provide whatever data, it thinks it wants the other end to receive, to the TLI and it is received as is at the other end. Optionally, after successful bind, the user program may i_push some modules on the stack before useint the connection. To implement rlogin under TLI you would simply do the following: write rlog-serve shuch that: Accepts first unit as "name" uses read()/write() to prompt/deal with password verification. { read() from TLI and write() to shell standin && read() from standin and write() to TLI} close local files exit. write rlogin such that: It takes destination machine name as option. knows the service code for rlog-serve opens provider passes TLI the address in a bind request on success i_push(es) the read()/write() interface on the STREAM (I forget the name, but you get it free) { read() form stdin and write() to TLI && read() from TLI and write() to standout} close all files when done exit. 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. If you do the three steps above you have rlogin. The remote shell stuff works exactly the same way. What more do you need? 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 the TCP/IP workings establishes a TCP/IP address for the TLI functions (much like 'adm' on the STARLAN network.) and routes the TLI functions up through a multiplexing STREAMS driver to where the TLI stuff can get it's hands on it. To whit: Listener Cloneable Module Hooks | | | | | | | | | | | -+------------------------------------------ | TLI to TCP/IP request format translator. {Multiplexing Kernel Module} | | TCP/IP Overseer {Deamon} (establishes all this on startup) | Other TCP/IP Entry Pionts | | | | | | | | | | | | | | | -+--------------------------------- | TCP/IP Driver {Multiplexing Kernel Module} Media Driver {Kernel Module} Interface {Hardware} To do it the other way would be a total mess. It is _expressly_ stated that TLI is a uniform service which 'insulates' the application form the _media dependant_ details of establishing and maintaining a connection. I would assume that there must therefore be a media dependant protocol on the other (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????????????? I can't really know until I find out more about TCP/IP; but This is my understanding of all the elements involved.) Rob.