heller@b11.ingr.com (Anne Heller) (02/07/90)
I have a question regarding binding to ports in UDP. Is it generally acceptable to allow binding more than once to a given port? (I know about the SO_REUSEADDR option in sockets, but we have a STREAMS implementation which complies with the AT&T Transport Provider Interface (TPI) standard, so not everyone is accessing UDP through sockets.) I'm sorry if this is a naive question, but I did not find anything addressing this issue in RFC768 (User Datagram Protocol) or in the RFC1122 (Requirements for Internet Hosts - Communication Layers). Thanks, Anne A. Heller -- uucp:...!uunet!ingr!b11!heller!heller
hwajin@ganges.wrs.com (Hwa Jin Bae) (02/08/90)
In article <7391@b11.ingr.com> heller@b11.ingr.com (Anne Heller) writes:
I have a question regarding binding to ports in UDP. Is it generally
acceptable to allow binding more than once to a given port? (I know
about the SO_REUSEADDR option in sockets, but we have a STREAMS
implementation which complies with the AT&T Transport Provider
Interface (TPI) standard, so not everyone is accessing UDP through sockets.)
It doesn't really matter whether you use sockets or TLI interface to access
the UDP/IP. The system calls (whether you use bind() or t_bind()) get turned
into STREAMS messages as they pass through the STREAM heads with types that TPI
multiplexor module understands (in case of bind request it would be
T_BIND_REQ type). Upon receiving such messages TPI multiplexor module will
call protocol specific bind routine to handle the bind request and return
the result of such binding. This sequence of kernel events is identical
for both TLI and socket based requests.
--
Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
hwajin@wrs.com (uunet!wrs!hwajin) "Omnibus ex nihil ducendis sufficit unum."guy@guy.uucp (Guy Streeter) (02/09/90)
hwajin@ganges.wrs.com (Hwa Jin Bae) writes: >In article <7391@b11.ingr.com> heller@b11.ingr.com (Anne Heller) writes: > I have a question regarding binding to ports in UDP. Is it generally > acceptable to allow binding more than once to a given port? ... >It doesn't really matter whether you use sockets or TLI interface to >access the UDP/IP... >... Upon receiving >such messages TPI multiplexor module will call protocol specific bind >routine to handle the bind request and return the result of such >binding. This sequence of kernel events is identical for both TLI >and socket based requests. I believe you misunderstood the question, which was how the UDP protocol-specific bind routine should handle a second bind request for an already-bound port. Answers received so far are in favor of allowing subsequent binds to succeed, and handing copies of received data to each. Seems that could get confusing... -- Guy Streeter b11!guy!guy@ingr.com ...uunet!ingr!b11!guy!guy
virgil@todal.touch.com (Virgil Champlin) (02/09/90)
In article <HWAJIN.90Feb7145434@ganges.wrs.com> hwajin@ganges.wrs.com (Hwa Jin Bae) writes: >> In article <7391@b11.ingr.com> heller@b11.ingr.com (Anne Heller) writes: >> I have a question regarding binding to ports in UDP. Is it generally >> acceptable to allow binding more than once to a given port? (I know >> about the SO_REUSEADDR option in sockets, but we have a STREAMS >> implementation which complies with the AT&T Transport Provider >> Interface (TPI) standard, so not everyone is accessing UDP through sockets.) > It doesn't really matter whether you use sockets or TLI interface to access > the UDP/IP. The system calls (whether you use bind() or t_bind()) get turned > into STREAMS messages as they pass through the STREAM heads with types that TPI > multiplexor module understands (in case of bind request it would be > T_BIND_REQ type). Upon receiving such messages TPI multiplexor module will > call protocol specific bind routine to handle the bind request and return > the result of such binding. This sequence of kernel events is identical > for both TLI and socket based requests. This is a bit wrong since the stream head knows nothing about TPI. It also doesn't answer the question "Is it generally acceptable to allow binding more than once to a given port?". I am also unaware of anything in UDP or TPI that prohibits more that one binding, concurrent or not, for CLTS providers. That doesn't mean that some implementations might disallow multiple concurrent binds but I do not know what they would use as a justification. Probably my old standby, "It seemed to make sense at the time.". There is the restriction with TPI that prohibits multiple concurrent binds with a "qlen" greater than zero which effectively disallows multiple concurrent "listens" (in the TLI sense) but this is for COTS, not CLTS providers . -virgil -- Virgil Champlin virgil@touch.com Campbell, CA "I got it, I got it, I ain't got it."
dcrocker@nsl.dec.com (Dave Crocker) (02/15/90)
"the UDP/IP. The system calls (whether you use bind() or t_bind()) get turned into STREAMS messages as they pass through the STREAM heads with types that TPI multiplexor module understands (in case of bind request it would be" Let me caution you. Each Streams implementation of TCP/IP appears to be quite different, in its interface both to sockets() and TLI. Especially TLI. The semantics for sockets() are well-defined, by virtue of having the BSD code as the reference implementation. However, the mapping of TLI syntax and semantics into TCP functionality is subject to considerable interpretation. Such flexibility is, always, exercised when there are multiple implementors. It is the great fun of open systems. Dave
dcrocker@nsl.dec.com (Dave Crocker) (02/15/90)
Well, there certainly is a difference between TPI and TLI, and I did miss your reference in the original note, but I'm afraid that I don't think it helps the issue much. TPI is the in-kernel interface. TLI is the application level mapping to TPI, as you describe. Unfortunately, the mapping between TPI and TCP (or UDP) is NOT subject to inherent or even universal definition. Basically, the TLI and TPI interfaces assumed a TP4 environment. (Yes, I know that they claim to be protocol independent. So did sockets.) But there still are places where a TCP implementor has choices of how to make some of the functionality available. The acid test is to see the continued need for IOCTL within common applications. Dave 28
hwajin@yuba.UUCP (Hwa Jin Bae) (02/17/90)
>Well, there certainly is a difference between TPI and TLI, and I did >miss your reference in the original note, but I'm afraid that I don't >think it helps the issue much. There are not just one, but *many* differences between TPI and TLI. I'm afraid you're confusing the comment about "mapping" between TLI to TPI as the "difference" between TLI and TPI. This is a trivial issue; they're called differently because they are different (but similar, as the similarity in the name suggests). What "issue"? >TPI is the in-kernel interface. TLI is the application level mapping >to TPI, as you describe. Redundancy. >Unfortunately, the mapping between TPI and TCP (or UDP) is NOT >subject to inherent or even universal definition. Basically, the >TLI and TPI interfaces assumed a TP4 environment. (Yes, I know that >they claim to be protocol independent. So did sockets.) But there >still are places where a TCP implementor has choices of how to >make some of the functionality available. The acid test is to >see the continued need for IOCTL within common applications. The reality is that there is no single universal definition of anything anyway. But TPI/TLI interfaces did *not* assume a TP4 environment; it assumed *any* OSI Transport Protocol (i.e. TP0,TP1, TP2,TP3 and TP4) environment. That's why the TPI STREAMS message types are modeled after the IS 8072 Transport Primitives. If you have the TPI spec you can find a table which maps each of the TPI message types to corresponding IS 8072 Transport Primitives, although there are several TPI extensions that don't have corresponding ISO T Primitives. It is all matter of "degrees"; sockets *are* protocol independent to a certain degree (IMHO, to a very satisfying degree) -- it currently provides interfaces for the following protocols: TCP, UDP, IP, ICMP, VMTP, XTP, XNS (SPP, PE, etc.), TP4, and several others. TPI and TLI are protocol independent to the same (arguably more) degree -- not at all perfect but pretty reasonable. They're reasonably useful for me and I can build useful stuff on top of them. And they're not really that bad to implement. That's the bottom line. What's your point anyways? hwajin -- hwajin@wrs.com (uunet!wrs!hwajin) "Omnibus ex nihil ducendis sufficit unum." Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
dcrocker@nsl.dec.com (Dave Crocker) (02/20/90)
The differences between sockets() implementations, as you state, is pretty much a case of implementation error, except to the extent that 4.2BSD and 4.3BSD have differences or to the extent that one fixes bugs in the semantics of them. (That is, the Berkeley implementations are the formal definition to sockets(), by definition. But, they have bugs. If one implements sockets() on a new platform, but fixes those bugs, you no longer conform to the 'formal' definition to sockets().) The differences between implementation of TCP available through TPI or TLI are deeper. Because the service interfaces to TPI and TLI are not perfectly matched to TCP, there are design choices to be made. They are, of course, made differently by different implementors and therefor, they are incompatible. The test of this issue is the extent to which an application can be ported from one Streams environment with TCP to another one, without code change. The answer is that many applications need to be changed. Dave 28
hwajin@yuba.UUCP (Hwa Jin Bae) (02/21/90)
[Dave Crocker writes...] >The differences between sockets() implementations, as you state, is >pretty much a case of implementation error, except to the extent that >4.2BSD and 4.3BSD have differences or to the extent that one fixes >bugs in the semantics of them. (That is, the Berkeley implementations >are the formal definition to sockets(), by definition. But, they >have bugs. If one implements sockets() on a new platform, but fixes >those bugs, you no longer conform to the 'formal' definition to >sockets().) Sure, most people already know this anyway. We've all been once or twice bitten by the differences between 4.1c, 4.2 and 4.3BSD differences. The differences you describe, namely those between 4.2 and 4.3 are minor compared to the differences between 4.1c and 4.2. People who've used them would know what I mean. Still, it is not that terribly hard to modify the application code to make them run on all of the above 4.* systems. In practice, the amount of code you have to change because of the differences in the socket interface for a given application is small compared to other system dependent changes that have to be made due to many other incompatible features such as TTY interface, directory handling, signals, and numerous other device specific ioctl's, etc. After all, that's why most people are hoping for POSIX althoug even with a formalized standard, it is pretty hard to get every implementation of any standard 100% compliant on anything. Given this, I find no substance in your elaboration of the differences in BSD socket interfaces; I fail to see any crucial point in your discussion... and it's getting pretty stale, fast. Are you complaining merely of the imperfections in the 4.* BSD standardization of the socket interface? If so, what's the point? Every other piece of software, when implemented by various vendors, will have the exact same problem unless people decide spend enough time and money to make some kind of application code compatibility conformance test as a requirement for the market. The current situation indicates that this type of incompatibility is trivial and not worth the resources that may be required for such efforts -- although it seems to be changing -- for the better. How many products are shipped with source codes anyway? Systems and application programmers can handle these simple modifications with minor difficulty -- thus, the economics rules. [I agree, in principle, this is not so desirable. But we're not living in a perfect world.] >The differences between implementation of TCP available through TPI or >TLI are deeper. Because the service interfaces to TPI and TLI are not >perfectly matched to TCP, there are design choices to be made. They >are, of course, made differently by different implementors and therefor, >they are incompatible. Pretty much the only difference, if any, that exists between various implementations has to do with the name of the STREAMS device you open via TLI to get a TCP STREAM or any other protocol STREAM. One other prevalent and possible difference seems to be the address binding semantics. Beyond these, there are *NOT* that many differences. Feel free to research your findings and come up with some major differences between different TLI implementation that will cause major grief and condemn network programmers to hell. I've written TLI applications and test codes for my implementation and I also ported them from Motorola Delta VME boxes running Unix V.3 to 80386 PC's running ISC TCP/IP and 386 running Excelan's TCP/IP and 386 running Streamlined TCP/IP and 386 running Wollongong's -- no doubt you're familiar with this one -- TCP/IP with *no* problem what so ever. It was easier to port the TLI application around over these various TLI implementations than to port 4.2BSD based socket application to 4.1c BSD based socket interface. Do you have actual experience in doing the actual porting of TLI applications to these various platforms? I do. Do you have actual experience working on implentations of TLI library, a TPI and TCP/IP in Unix kernel? I do. Your rhetorics sound good but clearly indicates your superficial knowledge. Besides, you still don't get it after all that I explained: there is *no* direct mapping going on between TLI and TCP in an AT&T TPI spec conformant environment. The mapping happens between TPI and TCP. And there is no problem there. Tell me about a specific problem that can not be reconciled. Give me some examples. As Douglas Hoftstadter once said, "You need to understand before you can criticize." >The test of this issue is the extent to which an application can be >ported from one Streams environment with TCP to another one, without >code change. The answer is that many applications need to be changed. Which ones? In what way? hwajin -- hwajin@wrs.com (uunet!wrs!hwajin) "Omnibus ex nihil ducendis sufficit unum." Hwa Jin Bae, Wind River Systems, 1351 Ocean Avenue, Emeryville, CA 94606, USA
gaw@SATURN.ACC.COM (...Glen............) (02/23/90)
Where could I find a specification on TPI? Thanks, Glen Warholic Advanced Computer Communications gaw@mercury.acc.com
hwajin@yuba.UUCP (Hwa Jin Bae) (02/23/90)
I'm not sure if AT&T publishes this spec for everyone. My copy is from the set that comes with Unix V.3.* source distribution documentation. It's primarily intended for the Unix systems developers and porting houses. You should call up AT&T and ask them about it. The title is _System V Porting Rules_. I don't work with Unix anymore so I can't give you the most up-to-date info on this. hwajin Wind River Systems
stevea@i88.isc.com (Steve Alexander) (02/23/90)
In article <9002201904.AA04950@yuba.WRS.COM> hwajin@yuba.UUCP (Hwa Jin Bae) writes: >Pretty much the only difference, if any, that exists between various >implementations has to do with the name of the STREAMS device you >open via TLI to get a TCP STREAM or any other protocol STREAM. One >other prevalent and possible difference seems to be the address >binding semantics. Beyond these, there are *NOT* that many differences. You missed the worst one of all. Options management. Most vendors use sockaddr_in for TCP & UDP addresses, but everybody has a different option format. Still, I agree that it's probably easier to port TLI applications between systems than socket applications, if for no other reason than that no two vendors can agree on where the header files go. The bottom line is that AT&T should have defined protocol bindings for TLI, or at least put pressure on vendors of UNIX System V add-on packages to be more compatible with each other. It'll probably be even worse when OSI implementations start proliferating, since there isn't even a reference standard like there was for UNIX TCP/IP implementations (at least not until 4.nBSD comes out, if then). -- Steve Alexander, Software Technologies Group | stevea@i88.isc.com INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
hwajin@wrs.wrs.com (Hwa Jin Bae) (03/01/90)
In article <1990Feb23.052940.5871@i88.isc.com> stevea@i88.isc.com (Steve Alexander) writes: >You missed the worst one of all. Options management. Most vendors use >sockaddr_in for TCP & UDP addresses, but everybody has a different option >format. Still, I agree that it's probably easier to port TLI applications >between systems than socket applications, if for no other reason than that >no two vendors can agree on where the header files go. Talk about trivial differences. The options data structure differs in varying degrees but for all pratical purposes the differences can be resolved with simple mods since in most cases the options data include fields for the option name and the value settings. Agreed, different vendors may choose to use different formats, etc. but that's what option means: optional. For example, options available for the sockets SO_DEBUG, SO_REUSEADDR, SO_KEEPALIVE, SO_LINGER, etc. in 4.3 BSD are just options. While some of these options are for a particular protocol -- as in TCP and SO_KEEPALIVE, SO_LINGER, etc. -- some are purely implementation dependent -- as in SO_DEBUG, SO_USELOOPBACK, etc. A TCP implementation is *not* required to implement all these options or provide interfaces to these options. The interface definitions for the options *should* be left undefined since vendors may choose to implement different options, etc. If you were to design a TLI interface would you design in every possible option data structure format that can be ever used? Aside from being an impossible task, it is a highly unwise thing to do as one cannot possibly plan for every possible vendor specific "enhancements", etc. If an application write chooses to use a given option provided by a given vendor it is his responsibility to support such software. Besides, how many TLI applications you know actually make heavy use of the options any way? Even the socket applications have "#ifdef"s everywhere for options like SO_OOBINLINE and SO_LINGER because not all implementation support these. >The bottom line is that AT&T should have defined protocol bindings for TLI, >or at least put pressure on vendors of UNIX System V add-on packages to be >more compatible with each other. I don't like Fascism. -- Hwa Jin Bae (hwajin@wrs.com) Wind River Systems
gaw@MERCURY.ACC.COM (...Glen............) (03/01/90)
Thank you for the information about where I could obtain the specification to TPI. Glen Warhoilic gaw@mercury.acc.com
stevea@i88.isc.com (Steve Alexander) (03/02/90)
In article <862@wrs.wrs.com> hwajin@wrs.wrs.com (Hwa Jin Bae) writes: >Talk about trivial differences. The options data structure differs in >varying degrees but for all pratical purposes the differences can be >resolved .... Sure, but they shouldn't have to be. The differences between 4.3BSD and System V Release 3 can be resolved too, but it's a waste of time. Why should I write the same code N different times in slightly different ways? If I #ifdef my TP0 implementation for WIN, ISC, and LAI, that's great, but what happens the when some other implementation comes along? >I don't like Fascism. Neither do I. That's not the point. The point is that there's more to a transport interface than primitives to support connecting, sending data, and disconnecting. Someone, either AT&T, or a group of interested vendors, should do protocol bindings for TLI, and define address formats, options, device names and so forth for TCP and UDP. Then TLI programs that want to access a TCP/IP transport stack could be written knowing that they would work regardless of the underlying TCP/IP implementation. Similar definitions could be developed for other types of transports. What's fascist about that? If you don't like fascism, don't use TLI or sockets. Write your own transport interface and use that. Strike a blow for freedom. Just don't expect anyone else to use it, because it would be fascist to force it on us. As an implementor of TCP/IP, I don't care what the address and options formats are as long as they work. As a user of TCP/IP, I care because I want my programs to be portable. Portable does not mean #ifdef'd. #Ifdef'ing only means that my program is portable to the systems that I've ported it to. I want it to be portable to as many systems as possible without modification. I can't do that with the current mess. -- Steve Alexander, Software Technologies Group | stevea@i88.isc.com INTERACTIVE Systems Corporation, Naperville, IL | ...!{sun,ico}!laidbak!stevea
hwajin@wrs.wrs.com (Hwa Jin Bae) (03/04/90)
In article <1990Mar2.054955.24392@i88.isc.com> stevea@i88.isc.com (Steve Alexander) writes: >Someone, either AT&T, or a group of interested vendors, >should do protocol bindings for TLI, and define address formats, options, >device names and so forth for TCP and UDP. I agree wholeheartedly. No problems there. I just don't like a single vendor defining some bogus standard and forcing it down our throats (as your original message seemed to suggest, but I guess you didn't mean that -- AT&T putting pressure on vendors of TCP/IP instead of assisting some commonly supported conformance specs for protocol bindings based on consensus). However, the problem also has to do with not just the lack of such "standardization" efforts (whatever happened to the X/OPEN thing that looked very much like TLI?) but the reality of corporate greed and politics. -- Hwa Jin Bae (hwajin@wrs.com) Wind River Systems