Xref: utzoo comp.dcom.lans:1596 comp.protocols.tcp-ip:4148 comp.protocols.iso:122 Path: utzoo!attcan!uunet!seismo!esosun!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: <1107@nusdhub.UUCP> Date: 19 Jul 88 04:05:42 GMT References: <7324@ico.ISC.COM> Organization: National University, San Diego Lines: 84 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 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.