rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/16/88)
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.
dougm@ico.ISC.COM (Doug McCallum) (07/17/88)
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.
rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/19/88)
in article <7324@ico.ISC.COM>, dougm@ico.ISC.COM (Doug McCallum) says: > Xref: nusdhub comp.dcom.lans:352 comp.protocols.tcp-ip:1080 comp.protocols.iso:44 > > 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 >>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. In my recolection, the originator of this thread said that he was "trying to write a TCP/IP <something> which would run over TLI," and was having a bitch of a time because "There was no preset way of handling addresses" in TLI. As far as an address being something that a user can be "prompted for" any user who wants to talk to machine 'X' had better know the "address" of machine X, or some alias which will relate. If the user has to type "AA093749823FEBCC836628973DA31.22" or "Go\nFind\nThe\nMachine\nThat\nHas\nService\nX" to get there, they can type this at their console, they can not, however, type in the spesification of a 45 byte structure and media spesific addressing scheme... As far as passing this "legible" address to the TLI provider, this is _exactly_ what takes place; If the dirver has to translate this to get the afor mentioned structure, fill a 50 byte real number, or go out and get name service, that is what it does, no questions asked. Hence teh value of the aledged uniformity. 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. 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. > Sorry to be so verbose, but the article prompted a comment since > it was so confused. The article _was_ confused because so was I. If the TLI is the difinition of an "OSI Transport Layer" then the presence of TCP/IP as the layer below this makes sense, in the sense that TLI is capable of being implemented _over_ TCP/IP. The original statement of the original poster that he wanted to place TCP/IP _over_ TLI made no sense to me... further, there would also be no point in writing said "application" if what he actually needs is TCP/IP information. Trying to put TCP/IP into TLI (a real squeze, and since TLI is supposed to be an _optional_ way of hiding the mess anyway...) I did not see what the problem was beyond bad choice of environment on the programmers part. The whole thread of putting something very TCP/IP into TLI and then bitching about the loss of direct address fiddling seems riduclous. Hence my quest for understanding. Rob.
guy@gorodish.Sun.COM (Guy Harris) (07/21/88)
> As far as an address being something that a user can be "prompted > for" any user who wants to talk to machine 'X' had better know > the "address" of machine X, or some alias which will relate. > If the user has to type "AA093749823FEBCC836628973DA31.22" or > "Go\nFind\nThe\nMachine\nThat\nHas\nService\nX" to > get there, they can type this at their console, they can not, > however, type in the spesification of a 45 byte structure and > media spesific addressing scheme... As far as passing this > "legible" The "legible" deserves to be in quotes here; no way is something such as "AA093749823FEBCC836628973DA31.22" usable. Sorry, if *I* want to send mail, I send it to "jblow@blow.com", not "jblow@AA093749823FEBCC836628973DA31.22". As for "media-specific addressing schemes", I assume that by "media" you mean "transport protocols" as opposed to "physical networks"; typically, the network-layer protocol will isolate you from having to deal with link-layer addressing. My machine's Internet address is "192.9.90.60" (a 4-byte string, with the four numbers there being the values of the four bytes), regardless of whether you're talking to it over a local Ethernet, a Sun Internetwork Router connection, a SLIP connection, or two tin cans and a string. > address to the TLI provider, this is _exactly_ what > takes place; If the dirver has to translate this to get the > afor mentioned structure, fill a 50 byte real number, or go out > and get name service, that is what it does, no questions asked. Wrong. The TCP and IP drivers in the STREAMS/TLI TCP/IP implementations I know of do *NOT* "goes out and get (the) name service", nor do they "translate" an ASCII string into a byte string. The code that *calls* TLI has to convert that hexadecimal monstrosity to a string of bytes, with the first byte having e.g. the hex value 0xAA, and stuff that down into the transport layer. > Hence teh value of the aledged uniformity. "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. > 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?). > 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).
rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/22/88)
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.
guy@gorodish.Sun.COM (Guy Harris) (07/23/88)
> 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. Excuse me, but this is nonsense; the difference between "actual bytes" and "109.90.42.6" is trivial relative to the difference between "sun.com" and "10.7.0.2". If TLI forced me to pass a string like "109.90.42.6" to it, that would be every bit as sad as if it forced me to pass that address down in binary form. > In essence this breaks the aledged uniformity. To implement the > TCP/IP and TLI over the same media, You don't "implement TLI over a medium". TLI/TPI is, in effect, an *interface* that "transport providers" implement. You implement a "TLI/TPI-conformant TCP" or a "TLI/TPI-conformant UDP" or a "TLI/TPI-conformant ISO TP4" or a "TLI-TPI conformant XNS SPP" or.... > the primitive kernel driver should be TCP/IP, and then a streams module > which can convert TLI requests into TCP/IP should be written. No, you implement a driver that provides the TCP or UDP protocol and that conforms to the requirements of TPI and TLI. That driver is what "converts TPI/TLI requests into TCP". > TCP/IP _is more_ complex, and therefore, to implement both TLI should be an > optional addition onto the TCP/IP. TCP and TLI are completely different types of things, so it's hard to say one is "more complex" than the other, except to say "TLI supports functions TCP doesn't provide" (which is true) or "TCP provides functions TLI doesn't support" (which is also true). > Then you place 109.90.42.6 in your Systems file; I refuse to put something as gross as "109.90.42.6" into any configuration file for a network utility; if I can't put the *name* of the machine there, that's unacceptable. There are, I believe, many *thousands* of hosts on the DARPA Internet; I know there are thousands of hosts on Sun's network. Sometimes hosts may change their addresses but not their names. Administering a network of that size by using addresses rather than names would simply be impractical. > The simple task of converting the string to the 4-byte couplet > is not beyond the scope of a STREAMS module, No, but it's not very useful, either. What you *really* want is a mechanism that can convert what you might call a "service specification" (i.e., "UUCP on host 'sun.com' over TCP") into an address in whatever form the protocol requires. UUCP (which, I infer from your mention of a "Systems" file, is the service to which you're referring here) would then ask for that service, and hand *that* to TLI. > 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. Are you actually familiar with TCP or IP, or is your only TLI/TPI experience with, e.g., STARLAN? If you haven't worked with TCP, you should probably study up on it first, and preferably on TLI-conformant TCP implementations, so you can discuss implementations of things other than STARLAN meaningfully, and support for multiple protocols in general, meaningfully. If all you know is STARLAN, you're unlikely to know what's involved in protocol independence....
mre@beatnix.UUCP (Mike Eisler) (07/26/88)
In article <1110@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >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 First of all, it is NOT adequate to pass 4 bytes. You need the Internet address plus the 2 bytes of port number that TCP service is listening. I'll agree that 109.90.42.6 is a commonly used, standard, clean way to pass an address to a driver. But I know of no commonly used form concatenates port numbers and "dot" addresses. >essence this breaks the aledged uniformity. To implement the What unformity? Where is there a standard written for specifying addresses to TCP/IP TLI conformant streams drivers? >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 What does complexity of TCP/IP have to do with whether TLI should be an option. What's complex, the protocol implementation, or the interface? If starlan and TCP/IP can both use the same interface, TLI, then they their interfaces are equally complex, and so by your logic all TLI compliant protocols should be implemented as two halves, your symbolic "uniforum half" and the half that everybody currently implements. Bye, bye performance. >As I said, doing TCP/IP _over_ TLI is stupid. They are *comprable* By this statement, I think you mean that to implement a TCP/IP protocol in user-land on top of some TLI compliant media driver (eg. X.25, ethernet, etc.) is stupid. I'm not so sure I agree. Somebody may want to proto-type a TCP/IP implementation first on a particular computer, before investing in the increased costs of kernel development and debugging, especially on a 3b2. :-) >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 Hey what exactly are you talking about anyway? TLI is comparable to TCP/IP? TLI is an interface. TCP/IP is a protocol. TCP/IP under TLI is an implementation. >The *purpose* of TLI _is_ to insulate you form the uglies ... >... Depending on what is required, you might >need to set an address like "109.94.60.2:rlogin" to properly implement You are assuming that this is the standard address representation for the login service residing on 109.94.60.2. I've never seen this format before. Vendors could implement infinite, incompatible variations of this ascii string format, eg: rlogin:109.94.60.2, 513.109.94.60.2, 2.1.109.94.60.1, 109.95.60.1:2.1, etc. >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. First you said that the *purpose* of TLI is to insulate you from "uglies" than you say that it is the purpose of the of "adm" program. Which is it? The "adm" program isn't on my copy of 5.3 source, so I assume it is something specific to starlan that assembles streams drivers and modules, and/or does name resolution. The various STREAMS TCP packages have similar tools and services to do the same, but difference is that Starlan has virtually one manufacturer and is proprietary to AT&T. AT&T can therefore enforce a standard address encoding that will be recognizable to all applications that use it on all machines that use those applications, eg. RFS. And I guess it is the "adm" program that embodies this enforcement. TCP has perhaps a half dozen or so suppliers of STREAMS implementations, each with their own "adm" thing and address encoding formats. The point is that without a well-defined, agreed upon standard, regardless of whether the encoding uses nice ASCII strings, or binary strings, each implementer is going to use his own encoding mechanism, resulting in incomptabilities. Telling me that TLI has solved this problem for me, because it solves it for the protocol you use (starlan), doesn't cut it. I'm using an open protocol that others are free to implement. If AT&T wants TLI to be the standard, then they should enhance it to define specifics for commonly used protocols (TCP, ISO/OSI/ X.25, SNA, DECNET). AT&T did this for starlan, why can't they do it for TLI? Sockets, for all the trashing people have done on them, do define and enforce address encodings for at least two protocols (XNS, TCP). Hence, everybody can rlogin, telnet, rcp, ftp, smtp, NFS, RPC, etc. to each other, as long as these things are built on sockets. That's not the case for RFS built on TLI over TCP. -Mike Eisler
rwhite@nusdhub.UUCP (Robert C. White Jr.) (07/28/88)
I am begining to suspect that I am exchanging POV with more than one other individual. For clarity, the thread to date is based on one posters lament about how dificult it was (for him) to write a TCP/IP interface which runs under TLI. Please re-read this sentince about a millino times--or at least until it soaks in throughly--before proceeding. Either that, or the postings are not being read, they are being "sampled." Similarly, you should at _least_ include the *entire* sentince on which you comment. Other wise all you are doing is foistering you on distortions of meaning on the readers. A prepositional phrase, or dependant clause all by itself does not an idea express... in article <61066@sun.uucp>, guy@gorodish.Sun.COM (Guy Harris) says: > Xref: nusdhub comp.dcom.lans:370 comp.protocols.tcp-ip:1132 comp.protocols.iso:52 > >> 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. > Excuse me, but this is nonsense; the difference between "actual bytes" and > "109.90.42.6" is trivial relative to the difference between "sun.com" and > "10.7.0.2". If TLI forced me to pass a string like "109.90.42.6" to it, that > would be every bit as sad as if it forced me to pass that address down in > binary form. True; I do understand that. This relates bact, however, to the "lament" that TLI (e.g. AT&T) did not spesify a "universal structure" (read to mean memory structure as in C or assem) which would interface to *every* kind of underlying protocol. (and went on to name: X.25, SNA, URP, TCP/IP [sic] and a couple of ones I didn't know) Put simply, such a structure would be preposterous and unworkable, therefore the "structure" stteled on was the "string." (e.g. a netbuf structure filled with an "arbitrary" string of characters meaningful to the application and the TLI driver.) To this end, what I wrote was *exactly* as menaingful as I intended. We have laready been through the: "But my address is 198.3.54.6 and not nusdhub.serve, so whay should I pass the latter" argument. I therefore, used the "addressing scheme" of choice (to my audience). >> In essence this breaks the aledged uniformity. To implement the >> TCP/IP and TLI over the same media, > You don't "implement TLI over a medium". TLI/TPI is, in effect, an *interface* > that "transport providers" implement. You implement a "TLI/TPI-conformant TCP" > or a "TLI/TPI-conformant UDP" or a "TLI/TPI-conformant ISO TP4" or a "TLI-TPI > conformant XNS SPP" or.... To this I must simply reply: "READ THE SPECS!" TLI may be implemented OVER *ANYTHING*; I even went so far as to explain that I was using the -loose- *ENGLISH* version of the word 'MEDIA.' To whit you may (were you to desire to) implement the following: TLI _over_ verification suit _over_ X.25 _over_ normal tty driver _over_ physical port _contected to_ a modem _connected to_ Tymenet. You may also make A TLI module which you may push above a TCP/IP endpoint to make the afore-mentioned TCP/IP driver-tree a "TLI CONFORMANT 'PROVIDER'": which is ALL the specs require of you. >> the primitive kernel driver should be TCP/IP, and then a streams module >> which can convert TLI requests into TCP/IP should be written. > No, you implement a driver that provides the TCP or UDP protocol and that > conforms to the requirements of TPI and TLI. That driver is what "converts > TPI/TLI requests into TCP". I KNOW the way is should be done when you have no other constraints. What I described conforms to the constraints provided. READ THE THREAD. Several articles back I went over (with pictures) TCP/IP- and TLI-cloning drivers over an overseer over a "media"; TLI-cloning driver over TCP/IP driver over "media"; et al ad nausium... Check your archive. >> TCP/IP _is more_ complex, and therefore, to implement both TLI should be an >> optional addition onto the TCP/IP. > TCP and TLI are completely different types of things, so it's hard to say one > is "more complex" than the other, except to say "TLI supports functions TCP > doesn't provide" (which is true) or "TCP provides functions TLI doesn't > support" (which is also true). No kidding???!!!??? Of course they are, but the basis of all this was someone who wanted to implement TCP/IP *over* TLI (patently dumb) and the waters you just re-muddied were almost clear. >> Then you place 109.90.42.6 in your Systems file; > > I refuse to put something as gross as "109.90.42.6" into any configuration file > for a network utility; if I can't put the *name* of the machine there, that's > unacceptable. There are, I believe, many *thousands* of hosts on the DARPA > Internet; I know there are thousands of hosts on Sun's network. Sometimes > hosts may change their addresses but not their names. Administering a network > of that size by using addresses rather than names would simply be impractical. Yes, I know about address names, verses real addresses. I am trying to keep the examples simple and well defined. Once again, If you simply say: "But I'll just throw away my spesifications and the desire of my employer and do it this way" all sorts of things become a lot easier. Similarly, if you just say: "This example is to basic, it allows someone form another environment to _understand_ so I better re-muck it up" you can justify all sorts of "better" things to say. The spesific issue *WAS* using the four byte address (c.f. to string or to structure) and my use of uucp as an example was to keep things both (1) on track to my audience, and (2) simple and aimed at my audience. >> The simple task of converting the string to the 4-byte couplet >> is not beyond the scope of a STREAMS module, > No, but it's not very useful, either. What you *really* want is a mechanism > that can convert what you might call a "service specification" (i.e., "UUCP on > host 'sun.com' over TCP") into an address in whatever form the protocol > requires. UUCP (which, I infer from your mention of a "Systems" file, is the > service to which you're referring here) would then ask for that service, and > hand *that* to TLI. I don't know weather you have read the specs for UUCP as relates to a TLI conformant provider. >> 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. > Are you actually familiar with TCP or IP, or is your only TLI/TPI experience > with, e.g., STARLAN? If you haven't worked with TCP, you should probably study > up on it first, and preferably on TLI-conformant TCP implementations, so you > can discuss implementations of things other than STARLAN meaningfully, and > support for multiple protocols in general, meaningfully. If all you know is > STARLAN, you're unlikely to know what's involved in protocol independence.... No, I am not farmilliar with the internal details of TCP/IP; my question about TCP/IP is mostly how this thread got started. As far as TLI is concerned, I have been through the "porting rules" doccument--which contains a description of *all* of the STREAMS requirements and functional spesifications necessary to make any STREAM represent a 'TLI conformant provider' (this includes state and precidence tables)-- and know exactly what is and is not required of a system for it to be TLI conformant. The essence of the discusion is: (1) Q: What structure should be passed to TLI? A: A "human readable" string. (2) Q: How can I [sic] implement a TCP/IP interface over a TLI network? A: You can't; you don't want to; the whole point of TLI is to allow/create a "simple and uniform" interface which will work with any provider. (3) Q: How am I supposed to do address translation under TLI? A: You don't; the driver writer has built the soft-to- hard address translation into the driver (if it is in fact conformant). Rob.
sas@pyrps5 (Scott Schoenthal) (07/28/88)
[ I have removed comp.protocols.iso from the Newsgroup distribution -- sas ] In article <1116@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >The essence of the discusion is: > >(1) Q: What structure should be passed to TLI? A: A "human readable" > string. I have tried to follow your "thread" and I must take exception to this statement. The point (as I see it) of the addressing discussion is that the structure of the address (in ISO jingo, the TSAP) that is passed to TLI is opaque. It is up to the implementation of the TLI-conformant transport provider as to how this is interpreted. Mike Eisler raised the point that different transport provider implementations that support the same protocol (he used TCP/IP addressing as an example) could interpret the address in different, arbitrary manners. What is lacking is the definition of an addressing structure (be it packed BCD, hexadecimal arrays, or ASCII strings) to be used for different communication protocol families (e.g., OSI, XNS, TCP/IP, etc) within the TLI framework. That, sir, is the point. >(3) Q: How am I supposed to do address translation under TLI? > A: You don't; the driver writer has built the soft-to- > hard address translation into the driver (if it > is in fact conformant). The question itself is a non sequitur. A more reasonable way of stating what I think you mean is: "How does an application programmer form address structures to pass to a TLI conformant provider while using the TLI user-library functions?" And the answer is (once again) that the format of the structure depends on the implementation of the provider. The provider renders the address structure passed to it (which is defined as part of the implementation of the provider) into whatever internal formats or uses it requires. Rob, I suggest that, if possible, you should somehow get access to System V source code. I think that the points made by Guy, Mike, and others will become more obvious. It is unfortunate that the publically available documentation does not make these issues more clear. sas ---- Scott Schoenthal sas@pyrps5.pyramid.com Pyramid Technology Corp. {sun,hplabs,decwrl}!pyramid!sas
dougm@ico.ISC.COM (Doug McCallum) (07/29/88)
In article <1116@nusdhub.UUCP> rwhite@nusdhub.UUCP (Robert C. White Jr.) writes: >I am begining to suspect that I am exchanging POV with more than one >other individual. You are. There are 3-4 of us. >For clarity, the thread to date is based on one posters lament about how >dificult it was (for him) to write a TCP/IP interface which runs under >TLI. Please re-read this sentince about a millino times--or at least until >it soaks in throughly--before proceeding. Ok, in your sentence, the operative word is "under". That is, TCP/IP interface is "under" the TLI. That's pretty clear. >Either that, or the postings are not being read, they are being "sampled." You might follow your own advice. ... >True; I do understand that. This relates bact, however, to the "lament" >that TLI (e.g. AT&T) did not spesify a "universal structure" (read to mean >memory structure as in C or assem) which would interface to *every* kind >of underlying protocol. (and went on to name: X.25, SNA, URP, TCP/IP [sic] >and a couple of ones I didn't know) Put simply, such a structure would >be preposterous and unworkable, therefore the "structure" stteled on was >the "string." (e.g. a netbuf structure filled with an "arbitrary" string >of characters meaningful to the application and the TLI driver.) No one suggested a "universal structure". What is needed and was suggested was a structure for each address family. It wasn't worded exactly that way, but that is what was said. Who settled on the "string" as the official form of address? You may have. The Starlan software may have, butI have not found it anywhere in the documentation. Please cite volume, chapter and verse so I can be enlightened. >To this end, what I wrote was *exactly* as menaingful as I intended. >We have laready been through the: "But my address is 198.3.54.6 and >not nusdhub.serve, so whay should I pass the latter" argument. I >therefore, used the "addressing scheme" of choice (to my audience). Actually, your audience seems to be disagreeing with you. ... >I KNOW the way is should be done when you have no other constraints. >What I described conforms to the constraints provided. READ THE THREAD. But the constraints are yours and not TLI or AT&T's. Could you point me at something that documents how things are supposed to be done? ... >> is "more complex" than the other, except to say "TLI supports functions TCP >> doesn't provide" (which is true) or "TCP provides functions TLI doesn't >> support" (which is also true). > >No kidding???!!!??? Of course they are, but the basis of all this was >someone who wanted to implement TCP/IP *over* TLI (patently dumb) >and the waters you just re-muddied were almost clear. Now, if your earlier sentence (included here for context) >For clarity, the thread to date is based on one posters lament about how >dificult it was (for him) to write a TCP/IP interface which runs under >TLI. Please re-read this sentince about a millino times--or at least until >it soaks in throughly--before proceeding. states what started this, then how do you get TCP/IP being implemented over TLI from TCP/IP "under" TLI? Before telling others to "read", you should do the same. ... >Yes, I know about address names, verses real addresses. I am trying to >keep the examples simple and well defined. But your examples only work in the simple and well defined universe. They don't work in the real universe the rest of us have to deal with. >Once again, If you simply say: "But I'll just throw away my spesifications >and the desire of my employer and do it this way" all sorts of things become >a lot easier. Similarly, if you just say: "This example is to basic, it >allows someone form another environment to _understand_ so I better >re-muck it up" you can justify all sorts of "better" things to say. Are you speaking as the authoritative voice of what AT&T wants people to do with TLI addressing? Again I ask, point me at any published specification that states that "strings" are what is specified. If you look on page 3-7 of the "AT&T UNIX(tm) System V Network Programmer's Guide", you will find a documented counter-example to your claim of strings being the specified address format. If you are interpreting the fact that the netbuf structure defines the "buf" field to be type "char *", well, "char *" is frequently used as a pointer to anything. I should also mention that when I worked on TCP support during the 386 V.3 port, we had to change the address convention used to conform to what AT&T required. That address format was a specific format for the struct sockaddr_in structure, it was not an ASCII string. Come to think of it, the "official" port supported ISO protocols with a very "binary" representation. This is documented in the "AT&T UNIX System V/386 System Administrator's Reference Manual" section tp4(7). ... >I don't know weather you have read the specs for UUCP as relates to >a TLI conformant provider. I have, what is it supposed to tell me that contradicts what the author said? You can either put in a phone number (in ASCII) or use \nnn notation to put in what you need. In other wrds, where RFS (which uses a different host file altogether) allows \xABCD, UUCP would require specifying in octal with the \nnn notation. ... >No, I am not farmilliar with the internal details of TCP/IP; my question >about TCP/IP is mostly how this thread got started. As far as TLI is >concerned, I have been through the "porting rules" doccument--which >contains a description of *all* of the STREAMS requirements and >functional spesifications necessary to make any STREAM represent a >'TLI conformant provider' (this includes state and precidence tables)-- >and know exactly what is and is not required of a system for it to be >TLI conformant. I've been through the porting rules as well. Not everyone ahs access to them. It is not supposed to be necessary to have the porting rules to do a Streams driver which is TLI conformant although it certainly helps. Where does it mention how an address is supposed to look? It doesn't mention it anywhere where I could find it. >The essence of the discusion is: I assume that the A: are your interpretations and may not necessarily be correct? >(1) Q: What structure should be passed to TLI? A: A "human readable" > string. Prove it. Give document, chapter, page and line. >(2) Q: How can I [sic] implement a TCP/IP interface over a TLI network? > A: You can't; you don't want to; the whole point of TLI is > to allow/create a "simple and uniform" interface > which will work with any provider. This isn't the issue so don't confuse things any further. >(3) Q: How am I supposed to do address translation under TLI? > A: You don't; the driver writer has built the soft-to- > hard address translation into the driver (if it > is in fact conformant). The real answer is that you can't with TLI at all. You need software that is not provided with V.3. Since your the one so insistant on being correct and having documentation to prove it, please do so. My documentation does not seem to have it. Give published dates also. Perhaps what an outsider can get is not the same as an insider. Doug McCallum Interactive Systems Corp. dougm@ico.isc.com
dougm@ico.ISC.COM (Doug McCallum) (07/29/88)
In an earlier article I mentioned that there should be a name server
to do the conversion. I didn't intend to imply a single name server
to handle "all" address formats or that only a single format should be
allowed, rather, I feel that a name server functional interface should
be specified. Each protocol implementation would then provide an
appropriate name server that the standard interface could access.
Each application woudl be implemented using the standard interface.
Finding which name server isn't difficult since you have to specify
the protocol via the first parameter to "t_open" anyway. That would
be enough information to provide a standard way of finding and
accessing a specific name server. It would also be possible to query
each resident name server and see if it could resolve the address or
not.
When a name is resolved, the resolver function would return a possible
list of opaque addresses. It would also have to return the size of
the address to provide a way to determine end of an address and a
count of how many addresses were returned. Some protocols might not
support or need multiple addresses while something like TCP/IP does.
A universal functional interface need not return a single fixed size
standard format object. The application does not need to know how to
parse the address. Some applications might, but then they would not
be particularly portable in any event. Most applications would just
hand the address to t_connect and wait for a connect or fail. This
would not be that hard to specify or even very difficult to implement.
You would have thought that AT&T would have understood the need of
name servers and related tools that become an absolute necessity with
large networks.
Doug McCallum
Interactive Systems Corp.
dougm@ico.isc.comrwhite@nusdhub.UUCP (Robert C. White Jr.) (07/30/88)
More or less at this point I think I am going to do the following: 1) Admit that the evidence indicates I am wrong. 2) Apologize for the tone of my previous posting. 3) Go for a long weekend away from my job and computer on the grounds that my attitude indicates excessive stress. 4) Re-assert my sense of falibility. 5) Set tuesday asside for an epic re-reading of the material. and 6) Resign myself for feeling stupid for a while. Rob. Disclaimer: Sometimes it is tough to admit that you are *not* the all seeing, all knowing, master of time, space, and demension. ;-)