Short History of Chaosnet

The article is correct that contact names were essentially the same as port numbers in TCP. This was a time of great experimentation in LAN protocols (and network protocols, what we would now call layers 1-4 or maybe -5). By the mid 70s most used thicknet (later called 10base5) coax using CSMA with exponential backoff (Metcalf&#x27;s greatest invention at PARC IMHO), so chaosnet was a local example (of several in New England alone, at the time). There wasn&#x27;t really anything off the shelf at the time.<p>CHAOSNET and lispms are historically intertwined it&#x27;s true, but hardly inextricably so. For example the file servers referred to in the article weren&#x27;t (until much later) lispms too, but our standard PDP-10 mainframes, so there were multiple implementations of chaosnet immediately, and it was also used for mainframe-mainframe communication (yes, you could transparently use remotely stored files back in the late 1970s). The earliest machines sold by Symbolics and LMI were just MIT CADRs build externally and badged by the manufacturer, by the time they built their own machines the Ethernet standard (also using 10base5) was starting to get traction and their machines used that instead. I did deploy and use a chaosnet system at the Centre Mondial in Paris because they had a KL-20 and some CADRs, but that was a rare case; possibly the only one outside USA, or possibly even outside the east coast of the USA.<p>Article is correct about the deep ties between BBN and MIT-AI. Honestly at the time of the ARPANET switching to TCP I really thought of the other address types as transitional anyway, so I&#x27;m not surprised more address types were never used. Though the whole point of the idea of an Internet was the union of all other networks (and the origin of the idea of the &quot;cloud&quot; -- a radical idea at the time, though focused on routing) the early model was either protocol-translating gateways or TCP.<p>When the net switched over from NCP to TCP it didn&#x27;t really feel like it affected me until 1984 when I could telnet directly from my machine at PARC (a Dolphin or Dorado -- they were also in a machine room with the display and kbd on my desk!) to my machines at the MIT AI lab. It seemed magical not to have to log into an intermediate machine. This was thanks to a pup gateway (pup was PARC&#x27;s equivalent to chaosnet, or perhaps I should say that the other way as pup was first) and sadly I eventually realized that it wasn&#x27;t using a chaosnet gateway on the MIT side (the PDP-10s had their own IMPs). But by the time I moved back to MIT this worked in the other direction as well.

I&#x27;ve always known CHAOS as the hmmm-that&#x27;s-weird way of finding out which version of BIND was running:<p><pre><code> $ dig @a0.org.afilias-nst.info version.bind txt chaos ;; ANSWER SECTION: version.bind. 0 CH TXT &quot;9.9.9-P5&quot; </code></pre> I never realised that once upon a time there was an actual Chaosnet protocol...

Oh wow, chaosnet is a great name! I learn something new with every post from Two-bit history!

There are several emulators that can talk Chaosnet, emulating Lisp Machines and the PDP-10.

Is ChaosNet remembered more accurately than Maryland summer parties in 1982? Let&#x27;s find out!<p>&gt; Usage of Chaosnet presumably waned as Lisp machines became less and less popular.<p>The relative drop in popularity of Lisp Machines wasn&#x27;t the primary reason for ChaosNet use to decline. Until the mid-1980s at MIT, ChaosNet was also widely used in everyday work on UNIX, VMS, and TOPS-20. ChaosNet was not focused on the small number of research groups that used Lisp Machines. By the mid-1980s, most operating system distributions included TCP&#x2F;IP. There were more deployed machines that could communicate over TCP&#x2F;IP than over ChaosNet. However, MIT did not yet have a supported IP network covering every building (where &quot;supported&quot; means either centrally supported by MIT, or supported by a major research lab, depending on the building in question).<p>The remaining reasons to use ChaosNet were network services and reliability. For example, SUPDUP arguably provided a much better remote-login experience than TELNET, and some (or possibly all) machines implemented SUPDUP only over ChaosNet, not over TCP. There may have been other important ChaosNet-only services on machines such as reagan (more commonly known as &quot;b&quot; -- for &quot;bonzo&quot;) at the AI Lab.<p>In some locations (possibly only on Vassar Street), keeping the ChaosNet software stack for reliability was worthwhile even though IP was obviously the only way to directly reach the whole outside world. Using the ChaosNet software stack, one could communicate within parts of the main campus as well as NE43, and relaying email to the outside world worked, at least often. That was sometimes the only networking that a person needed to accomplish their work. In building 36 and 38, the earliest set of IP addresses was on the 18.27&#x2F;16 network. That specific implementation of IP may have involved some type of protocol tunneling or protocol translator. At one time, this was maintained at the Digital Signal Processing Group (sixth floor of 36) and may have run on a machine named yosemite-sam (or some other Looney Tunes character). This was largely successful, but not really &quot;supportable.&quot; Eventually, a separate network was built in 36 and 38 using 18.62&#x2F;16 IP addresses, and any machine wired to that network could not use ChaosNet services elsewhere. Over time (more than a year), every machine moved off of 18.27&#x2F;16 and onto 18.62&#x2F;16. At that point, it rarely made any sense for anyone outside of NE43 to build or enable ChaosNet support on any machines.<p>Even before this, the cost&#x2F;benefit became too high for some people to bother building, installing, or enabling ChaosNet. For example, Alan Wu, who was the head of the Electrical Engineering and Computer Science Educational Computing Facility (EECS ECF) made a decision in the mid-1980s that his staff would no longer compile ChaosNet into the kernel on their BSD machines. The reasons may have included the extra work of a nonstandard build tree, and machine crashes within the ChaosNet code. Similarly, syaadmins in other places saw that it didn&#x27;t make sense to devote any resources to the small benefits of ChaosNet.<p>On a larger scale, Project Athena BSD kernels did not include ChaosNet code (or, if they ever did at the beginning, it was discontinued after a while or was never commonly used). However, Athena was probably not a major factor in the decline of ChaosNet. Athena workstations were never connected to unsupported networks such as 18.27&#x2F;16, and Athena users typically had no SUPDUP use case. ChaosNet use was already mostly gone (outside of NE43) before individual faculty and staff were generally able to request Athena workstations for their offices or labs.