Path: utzoo!attcan!uunet!ogicse!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!yuba.UUCP!hwajin From: hwajin@yuba.UUCP (Hwa Jin Bae) Newsgroups: comp.protocols.tcp-ip Subject: Re: UDP bind question Message-ID: <9002201904.AA04950@yuba.WRS.COM> Date: 20 Feb 90 19:03:33 GMT References: <9002201434.AA04791@dcrocker.pa.dec.com> Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 92 [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