Xref: utzoo comp.dcom.lans:1602 comp.protocols.tcp-ip:4170 comp.protocols.iso:125 Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!oliveb!sun!gorodish!guy From: guy@gorodish.Sun.COM (Guy Harris) Newsgroups: comp.dcom.lans,comp.protocols.tcp-ip,comp.protocols.iso Subject: Re: TCP/IP _over_ TLI???? (was: TLI transport specific addresses) Message-ID: <60781@sun.uucp> Date: 21 Jul 88 05:57:45 GMT References: <7324@ico.ISC.COM> <1107@nusdhub.UUCP> Sender: news@sun.uucp Lines: 73 > 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).