<div dir="ltr">FTP Software - TCP/IP for DOS/Windows - went belly up with Microsoft integrated this into a version of their OS.<div><br></div><div>IBM, DEC and HP did implementations in the research labs without charge to DARPA.</div><div><br></div><div>v</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 25, 2017 at 2:27 PM, Jack Haverty <span dir="ltr"><<a href="mailto:jack@3kitty.org" target="_blank">jack@3kitty.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The history of TCP implementations was driven by non-technical forces<br>
too. As the saying goes -- "Follow the money."<br>
<br>
ARPA paid for the development of most if not all of the very early TCP<br>
implementations: the BBN-TENEX and LSI-11 for the Packet Radio project,<br>
my own PDP-11/40 Unix implementation as part of a Network Security<br>
research program, Sax/Edmond's HP-3000 code, Braden's IBM work at UCLA,<br>
Clark/Chiappa at MIT, Mills LSI-11 at UDel, and Gurwitz Vax<br>
implementation. Probably more I've forgotten. Wingfield's PDP-11/70<br>
was funded, IIRC, by DCEC, the research arm of DCA - so it represented a<br>
tiny step from the research/ARPA world into the operational side.<br>
<br>
ARPA also paid for development of OSes, in particular BSD. As the TCP<br>
implementations were completed, ARPA stopped funding further<br>
TCP-specific work, and, also IIRC, made those baseline implementations<br>
generally available. Berkeley continued BSD with ARPA funds, which<br>
evolved into Sun. Big government contractors (motivated by the<br>
contractual requirement to support TCP) built TCPs as they needed.<br>
<br>
Note also that the "await/capac" Unix interface was created by Randy<br>
Rettberg and I to be the minimal functionality, with absolute minimal<br>
kernel code footprint, that we knew was needed to be able to write<br>
network applications - ftp, telnet, etc. The goal was to cram it into<br>
the PDP-11/40, not to make a definitive interface for general Unix use.<br>
So it's not surprising that sockets took over.<br>
<br>
Also, someone commented that it would have been possible to do<br>
networking with standard Unix primitives at the time, by having multiple<br>
processes interacting. We actually tried that. More accurately, Ray<br>
Tomlinson (yes the same one) ported a network security application that<br>
had been running on BBN-TENEX into a Unix implementation with a dozen or<br>
so interacting processes. With all of the context switching it was so<br>
slow that it was totally unusable. Plan B was await/capac to make it<br>
possible to use a single Unix process instead.<br>
<br>
Hardware vendors built TCPs too, such as the C/70. IIRC, the C/70<br>
development for network management was partially funded by DCA, so that<br>
would have provided support for TCP development too.<br>
<br>
Startups popped up to fill gaps. Microsoft was a tad late to the party,<br>
and a slew of small companies created TCPs for DOS/Windows. I recall<br>
circa 1990 we had to deal with testing our software using 30+ different<br>
TCP implementations for Windows that were then in common use.<br>
<br>
Historians may find DNA traces of some of those baseline 1980-ish<br>
implementations in the later systems. My gut feeling is that the<br>
choices that were made were not necessarily driven much by technical<br>
evaluations, but more often by pragmatic considerations - availability<br>
of code, or of personnel with relevant experience.<br>
<br>
So, when you seek to unravel the history of TCP (and the Internet), I'd<br>
suggest also following the trails of the money, the people, as well as<br>
the software to understand why things happened the way they did. That<br>
won't be easy...<br>
<br>
HTH,<br>
/Jack<br>
<div class="HOEnZb"><div class="h5"><br>
On 10/25/2017 08:27 AM, James J Dempsey wrote:<br>
> Paul Ruizendaal <<a href="mailto:pnr@planet.nl">pnr@planet.nl</a>> wrote:<br>
><br>
>>> On 24 Oct 2017, at 20:52, James J Dempsey <<a href="mailto:jjd@jjd.com">jjd@jjd.com</a>> wrote:<br>
>>><br>
>>> The C/70 (as well as the C/60) definitely did have a TCP/IP stack. One of<br>
>>> the first uses of the C/70 was to build and run the NU Network Monitoring<br>
>>> system. When I arrived at BBN in the Summer of 1981, we were already on<br>
>>> track to transition ARPANET to TCP/IP, which as we know eventually happened<br>
>>> on 1 Jan 1983.<br>
>><br>
>> Thanks for confirming that. Would you recall if the C/70 used the sockets API<br>
>> or the earlier arpanet API? (I would suspect the latter).<br>
>><br>
>> If the former, it would be the only back port of sockets to V7 that I?m<br>
>> aware of (unless one thinks of 2.8BSD/2.9BSD as being V7).<br>
><br>
> If you check out RFC 801 (written Nov 1981), Rob Gurwitz (who wrote BBN's<br>
> UNIX TCP implementation) says of "BBN C70 UNIX":<br>
><br>
> The C/70 processor is a BBN-designed system with a native<br>
> instruction set oriented toward executing the C language. It<br>
> supports UNIX Version 7 and provides for user processes with a<br>
> 20-bit address space. The TCP/IP implementation for the C/70 was<br>
> ported from the BBN VAX TCP/IP, and shares all of its features.<br>
><br>
> This version of TCP/IP is running experimentally at BBN, but is<br>
> still under development. Performance tuning is underway, to make<br>
> it more compatible with the C/70's memory management system.<br>
><br>
> In the same RFC, Rob writes of the BBN VAX UNIX TCP implementation:<br>
><br>
> The VAX TCP/IP implementation is written in C for Berkeley 4.1BSD<br>
> UNIX, and runs in the UNIX kernel. It has been run on VAX 11/780s<br>
> and 750s at several sites, and is due to be generally available in<br>
> early 1982.<br>
><br>
> The implementation conforms to the TCP and IP specifications (RFC<br>
> 791, 793). The implementation supports the new extended internet<br>
> address formats, and both GGP and ICMP. It also supports multiple<br>
> network access protocols and device drivers. Aside from ARPANET<br>
> 1822 and the ACC LH/DH-11 driver, experimental drivers have also<br>
> been developed for ETHERNET. There are user interfaces for<br>
> accessing the IP and local network access layers independent of<br>
> the TCP.<br>
><br>
> Higher level protocol services include user and server TELNET,<br>
> MTP, and FTP, implemented as user level programs. There are also<br>
> tools available for monitoring and recording network traffic for<br>
> debugging purposes.<br>
><br>
> Continuing development includes performance enhancements. The<br>
> implementation is described in IEN-168.<br>
><br>
> IEN-168 (available here <a href="https://www.rfc-editor.org/ien/ien168.txt" rel="noreferrer" target="_blank">https://www.rfc-editor.org/<wbr>ien/ien168.txt</a> ) does not<br>
> contain the word "socket", so I suspect that that means the BBN-UNIX<br>
> implementation of TCP didn't contains the socket interface, initially.<br>
><br>
> In "Networking Implementation Notes 4.4BSD Edition" (<br>
> <a href="https://docs.freebsd.org/44doc/smm/18.net/paper.pdf" rel="noreferrer" target="_blank">https://docs.freebsd.org/<wbr>44doc/smm/18.net/paper.pdf</a> ) Sam Leffler and Bill<br>
> Joy acknowledge the BBN TCP/IP implementation:<br>
><br>
> Many of the ideas related to protocol modularity, memory management, and<br>
> network interfaces are based on Rob Gurwitz’s TCP/IP implementation for the<br>
> 4.1BSD version of UNIX on the VAX [Gurwitz81].<br>
><br>
> [Gurwitz81] is IEN-168.<br>
><br>
> Finally, at <a href="http://www.xbbn.org/note-12.html" rel="noreferrer" target="_blank">http://www.xbbn.org/note-12.<wbr>html</a> there is this description of<br>
> sockets and BBN's TCP implementation:<br>
><br>
> The BBN BSD TCP was the standard TCP for 4BSD and BSD UNIX 4.1. However, in<br>
> BSD 4.2, the team at U.C. Berkeley created their own and very different<br>
> implementation of TCP/IP (using the now familiar socket interface developed<br>
> by Bill Joy and Sam Leffler of Berkeley along with Gurwitz). BBN promptly<br>
> revised its TCP implementation to use the socket interface, and for about a<br>
> year there was a battle to determine whose networking code would take<br>
> precedence. Although the BBN code won some adherents, and was licensed to<br>
> several computer vendors, the Berkeley code won the battle.<br>
><br>
> I hope this clears that up.<br>
><br>
> --Jim Dempsey--<br>
><br>
> _______<br>
> internet-history mailing list<br>
> <a href="mailto:internet-history@postel.org">internet-history@postel.org</a><br>
> <a href="http://mailman.postel.org/mailman/listinfo/internet-history" rel="noreferrer" target="_blank">http://mailman.postel.org/<wbr>mailman/listinfo/internet-<wbr>history</a><br>
> Contact <a href="mailto:list-owner@postel.org">list-owner@postel.org</a> for assistance.<br>
><br>
_______<br>
internet-history mailing list<br>
<a href="mailto:internet-history@postel.org">internet-history@postel.org</a><br>
<a href="http://mailman.postel.org/mailman/listinfo/internet-history" rel="noreferrer" target="_blank">http://mailman.postel.org/<wbr>mailman/listinfo/internet-<wbr>history</a><br>
Contact <a href="mailto:list-owner@postel.org">list-owner@postel.org</a> for assistance.<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">New postal address:<div>Google<br><div>1875 Explorer Street, 10th Floor</div><div>Reston, VA 20190</div></div></div></div>
</div>