Will@cup.portal.com (Will E Estes) (07/28/90)
Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan, and FTP software written from scratch, or is the code basically just modified Berkeley code? Why is it so difficult to write a good TCP/IP? I am amazed that there are companies whose entire R&D seems to center around writing the TCP/IP protocol and supporting applications. Is it really that difficult? You would think that if you started with the Berkeley stuff it wouldn't be that difficult to improve it, or do legal restrictions prevent you from using the Berkeley stuff as a base? (You would think that it would be pretty easy to license the Berkeley code from the owner if it isn't public domain already....) Will Estes (sun!portal!cup.portal.com!Will)
imp@dancer.Solbourne.COM (Warner Losh) (07/28/90)
: Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan, : and FTP software written from scratch, or is the code basically just modified : Berkeley code? WIN/TCP for VMS version 5.1 is based on BSD 4.3 Mutlinet (by TGV, sometimes sold by Excelan) is based on BSD 4.3 Tahoe Excelan? Don't know for sure. Fusion: They wrote their own, then ported it to VMS WIN/TCP for DOS version 4.1 is based on a very old version of IP/TCP written at MIT. Most of the original code is gone now, but the copyright notices remain. FTP software is also based on the MIT IP/TCP, but I don't know how much they have changed it. Based on what I've seen from them at trade shows and on the net, I would guess that this is quite alot. I also got the impression that is president had a great deal to do with the original IP/TCP implemetation. The large number of people that use BSD is a reflection of its unrestrictive licensing requirements. Warner -- Warner Losh imp@Solbourne.COM Boycott Lotus. #include <std/disclaimer>
romkey@asylum.sf.ca.us (John Romkey) (07/28/90)
FTP Software's code isn't based on Berkeley's. It's based on MIT's PC/IP, some of the primary authors of which (including me) founded FTP. Internally, it bears little resemblance to PC/IP these days, having been pretty heavily rewritten. As for porting the Berkeley code, I find that people who don't know it well take perhaps 4 months to bring up a port of it - it really wants to live inside a UNIX kernel. They still find that this is cheaper and faster than writing a TCP implementation from scratch. One of the reasons is that the Berkeley code is a *very* good protocol engine with a lot of time in the field. There are a lot of tricks to bringing up a TCP implementation from scratch, some of which are decoding the RFC's sufficiently well to get something "right", figuring out the stuff that's not in the RFC's (one of the reasons behind writing the Host Requirements RFC's, which represent "the wisdom of the ages"), and testing against the great many other TCP's out there. Now, yes, many of them are ports of the Berkeley code, but there have been several versions of the Berkeley code with varying levels of protocol compliance and bugginess, and many vendors manage to introduce their own bugs in their ports because they don't really have a deep understanding of what they're doing. A few years ago, it was possible to have two different people go and sit in different rooms and write TCP/IP implementations from scratch and not have them interoperate at all, or have them interoperate poorly and slowly. I believe this is largely still the case now - a TCP written in a vacuum isn't worth much. There are a lot of issues involved in getting this byte-oriented, sliding window protocol to work over network media spanning less than 300 bps to over 100Mbps from extremely noisy network links to perfect network transmission media, with a variety of latencies and having to interoperate in a world of many perhaps less than bug-free or well-tuned implementations. And then you want it to work well. The Berkeley code represents a lot of experience rolled into one piece of software. The edges that have to be glued into the system you roll it into are pretty rough; it's not really designed for that, but what you get is worth a lot, especially when real network wizards are expensive and hard to find (and many have better things to do than write "another" TCP implementation). Likewise, FTP Software has spent a lot of time getting that experience into its code. A lot of FTP's support time is dealing with *other* vendor's problems. A lot of development work has gone into making code that's bulletproof (or at least resistant) in the face of erratic behaviour on the part of its network peers. I think you'll find there are very few individual TCP's out there. The vast majority are ports of the Berkeley code. Before 4.2BSD, there was a 4.1 TCP from BB&N, which was rewritten (as I recall) into 4.2's code, and for a while 4.2 shipped with both until only Berkeley's was included. MIT's PC/IP was developed based on some code Dave Clark wrote while on sabbatical in England and brought back to MIT with him; this spawned a different line of UNIX TCP's, and a number of vendors implementations are based on PC/IP. Most of these vendors have probably put a lot of work into rewriting the TCP module, though, because the one MIT provided was inappropriate and inadequate for general purpose use. Phil Karn rolled his own in KA9Q (he'll correct me if I'm wrong). I believe the NCSA telenet TCP is probably independent, though I've never read the source code for it. Then there are TCP's for other operating systems, like MIT's ITS (on a PDP-10), the several varieties of Lisp Machines, Multics, and TOPS-20, all of which are independent strains. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com King Kong died for your sins.
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (07/28/90)
Are most of the commercial TCP/IPs sold by companies like Wollongong,
Excelan, and FTP software written from scratch, or is the code
basically just modified Berkeley code?
I would expect that most of the "large computer" commercial tcps are based
on some version of the Berkeley code. Most of the PC TCPs are probably
based on the MIT PC/IP code, although these have mutated more.
Why is it so difficult to write a good TCP/IP?
It's not. But it isn't easy either. Read the Host Requirements RFC
sometime. It's much easier to copy code from someone who has it almost
right than to start from scratch. I once made a bunch of improvemets to
the TCP for top20, but I reached the point where it would be easier to
port berkeley code than to start from scratch to implement some new
useful features. (Even though it would have meant figuring out a way
to integrate C into an all assembler OS. Fortunately, I got a different
job about then... :-)
I am amazed that there are companies whose entire R&D seems to center
around writing the TCP/IP protocol and supporting applications. Is it
really that difficult?
Well, entire companies have been know to support applications that DON'T
involve a network. It is clearly more difficult if there is a network too.
People want their applications (and their networks) without having to
understand anything about the underlying technology. Making the network
invisible is very hard. I wish more comercial companies put effort into
it. (There ought to be a mail system easier to install than sendmail...)
You would think that if you started with the Berkeley stuff it
wouldn't be that difficult to improve it, or do legal restrictions
prevent you from using the Berkeley stuff as a base?
Berkeley TCP/IP was (is?) developed under government contract, which makes
it pretty much available. The problem used to be the pieces of unix that
it contained. Of course, porting the code to a non-unix environment presents
opportunities for numerous bugs to creep in. And keeping up with the rate
of change the tcp code goes through is pretty tough too. And if you're
talking about improvements to the applications, you have to remember that
"improvement" is in the eye of the beholder...
BillW
-------schwartz@groucho.cs.psu.edu (Scott Schwartz) (07/29/90)
In article <12609238094.10.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: There ought to be a mail system easier to install than sendmail... There is. Rayan Zachariassen's Zmailer, even in alpha test, is easier to use and more reliable than sendmail.
hascall@cs.iastate.edu (John Hascall) (07/30/90)
In article <32140@cup.portal.com> Will@cup.portal.com (Will E Estes) writes: }Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan, }and FTP software written from scratch, or is the code basically just modified }Berkeley code? Why is it so difficult to write a good TCP/IP? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Try it sometime!! It has taken me over a year of evenings (as many as my wife will stand for :-) to put together a good solid ARP,IP,ICMP,UDP,TCP,DNS under VAX/VMS (working entirely in assembly doesn't help!). And that still leaves all the "user" stuff (Telnet, FTP, etc...). [And since the arrival of 300+ DECstations, VAXes look to be dead here soon, sigh.] A big part of the difficulty is all those RFCs -- if you have a working implementation and a new "good thing" comes out, it is usually not that hard to add it (unless of course your code looks nothing at all like BSD's :-( but to try to get all of those things working while more are being thought-up every day is rather a losing battle. By my estimation, most (at least half) of the difficulty is in TCP. The other half was reverse-engineering DEC's "backdoor" into the ethernet driver. Leaving the rest as the third half. John Hascall / john@iastate.edu / hascall@atanasoff.cs.iastate.edu
karn@envy.bellcore.com (Phil R. Karn) (08/01/90)
In article <9007272321.AA09325@asylum.sf.ca.us>, romkey@asylum.sf.ca.us (John Romkey) writes: |> Phil Karn rolled his own [TCP] in KA9Q (he'll correct |> me if I'm wrong). True. My TCP was written from scratch starting in late 1985. Its first platform, believe it or not, was the Xerox 820, a 64K CPM Z-80 system. It moved fairly quickly to the PC after that. In the next several years various refinements such as the Van Jacobson mods were added. It is fairly stable now, although I recently improved the slow-start code. My TCP is probably the only one that was written essentially on a dare. In 1985 the amateur packet radio community was swept by a raging protocol war that would bring smiles of recognition to this group. In one camp were the connection-oriented ISO/CCITT/X.25 lackeys, and in the other were the Internet TCP/IP people, the only ones who knew what they were doing (nah, I'm not biased :-)). One of the more rabid members of the opposing camp stridently argued that TCP was so incredibly complicated that I could NEVER cram it into anything less than a full-blown VAX, to say nothing of personal computer hardware that could be afforded by the average radio ham. Not one to be told I couldn't do something, I sat down with RFC-793 and started coding. I had it limping along in a month or two, in time to show at the ARRL Computer Networking Conference in February 1986. However, the whole project quickly got into my blood, and over 5 years later I'm still at it. And the guy who had originally challenged me has still not conceded defeat. I *strongly* agree that you can't write a good TCP in a vacuum. Much of my early testing took place over a SLIP link which revealed some, uh, gaps in RFC-793's wisdom on round trip timing algorithms. Our CSNET/X.25Net connection to ARPANET at the time was marvelous for stress testing my IP reassembly and TCP retransmission and resequencing code. And running on a slow, memory starved machine gave one a strong incentive to write tight code... Phil
mwp@ubeaut.OZ.AU (Michael Paddon) (08/01/90)
From article <32140@cup.portal.com>, by Will@cup.portal.com (Will E Estes): > Are most of the commercial TCP/IPs sold by companies like Wollongong, Excelan, > and FTP software written from scratch, or is the code basically just modified > Berkeley code? Why is it so difficult to write a good TCP/IP? I am > amazed that there are companies whose entire R&D seems to center around > writing the TCP/IP protocol and supporting applications. Is it really that > difficult? You would think that if you started with the Berkeley stuff it > wouldn't be that difficult to improve it, or do legal restrictions prevent > you from using the Berkeley stuff as a base? (You would think that it would > be pretty easy to license the Berkeley code from the owner if it isn't > public domain already....) The Berkeley code is not public domain; it is copyrighted by the Regents of the University of California. However, the BSD code *is* freely available as source. Obviously you can't sell it, but you can sell any modifications you make to it. A fair amount of the socket layer is missing from the BSD distribution because there is AT&T code embedded in it. From what I've seen of the Exelan and Wollongong IP implementations, much has been borrowed from the BSD code, so it is likely that they are both based on it originally. As for how easy it is to port... I've been doing this for the last six months, on and off, onto NCR towers under System V. We rewrote the socket interface as a library/driver combination, pulled out unix domain sockets and the NS protocols and hacked select severely. The SLIP driver needed a complete reworking because it is far too BSD dependent. The mbuf code required extensive thought. Inetd, syslogd, rsh, rcp and other utilities needed to be hacked. Another problem was that the BSD code is not bug free. Has anybody noticed how in_losing() interacts with SLIP? Getting all that working was about 2-3 man months worth of effort. Since then, we've been porting to the 850 multiprocessor tower. This is much more difficult because the BSD code never (and could never) be designed with that architecture in mind. In summary, porting IP from BSD sources is straightforward but not trivial. Michael ------------------------------------------------------------------- | | EasyNet: meo78b::paddon | | | Internet: paddon@meo78b.enet.dec.com | | Michael Paddon | ACSnet: mwp@ubeaut.oz.au | | | ACSnet: mwp@munnari.oz.au | | | Voice: +61 3 895 9392 | -------------------------------------------------------------------
kevinr@moe.Tandem.COM (Kevin J. Rowett) (08/09/90)
In article <1990Aug1.013502.25874@bellcore-2.bellcore.com>, karn@envy.bellcore.com (Phil R. Karn) writes: |> |> In article <9007272321.AA09325@asylum.sf.ca.us>, romkey@asylum.sf.ca.us |> (John Romkey) writes: |> |> Phil Karn rolled his own [TCP] in KA9Q (he'll correct |> |> me if I'm wrong). |> |> True. My TCP was written from scratch starting in late 1985. Its first Not to mention the hundreds of AR people who've tested and improved Phil's work over the last few years. KA9Q TCP/IP can't be considered a contribution by one person, although the orignator does write some very fine code! N6RCE |>I *strongly* agree that you can't write a good TCP in a vacuum. >Phil
romkey@asylum.sf.ca.us (John Romkey) (08/10/90)
Date: 1 Aug 90 05:40:34 GMT From: decwrl!ucsd.edu!sdd.hp.com!samsung!munnari.oz.au!mtiame!ubeaut!mwp (Michael Paddon) The Berkeley code is not public domain; it is copyrighted by the Regents of the University of California. However, the BSD code *is* freely available as source. Obviously you can't sell it, but you can sell any modifications you make to it. 4 out of 5 network companies do it. I believe that you can sell it; however, you have to credit the source of the software. Of course, the difference here is rather a moot point; nobody sells the Berkeley code without making a bunch of changes too, unless they're selling a 4.xBSD system. - john romkey USENET/UUCP: romkey@asylum.sf.ca.us Internet: romkey@ftp.com King Kong died for your sins.