Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!sdd.hp.com!decwrl!ucbvax!asylum.sf.ca.us!romkey
From: romkey@asylum.sf.ca.us (John Romkey)
Newsgroups: comp.protocols.tcp-ip
Subject: re: Are Commercial TCPs Berkeley Code Or Custom?
Message-ID: <9007272321.AA09325@asylum.sf.ca.us>
Date: 28 Jul 90 06:21:18 GMT
References: <32140@cup.portal.com>
Sender: daemon@ucbvax.BERKELEY.EDU
Reply-To: romkey@asylum.sf.ca.us
Organization: The Internet
Lines: 68

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.