Hooray for the sockets interface

In 1983, the University of California, Berkeley campus (UCB) released version 4.2 of its UNIX operating system, the Berkeley Standard Distribution (BSD). For many people, this is the ‘epoch event’ that defines the birth of online services, because it is the version that released the BSD ‘sockets’ model of networking into the world. In effect, the ‘right place, right time’ combined for computing systems and an operating system to run on them. This led to a massive increase in access to network services worldwide.

The installation of this first ubiquitous network approach was by tape, which you got in the mail.

To modern eyes, this may seem strange, given that modern operating system installation is most often a network-driven event. If you do not download a full ISO image or bootable VMDK disk image from the network, you tend to download a smaller system that bootstraps from the network. This is normal — the network is assumed.

Back in the 1980s, while ‘a network’ might exist, it was both too narrow — dial-up telephone at speeds as low as 1200 or 2400 baud — and lacked common protocols to specify how to find and fetch content. Even if you had access to ‘the network’, it was difficult to reliably retrieve something like the binary code of a new operating system. It looked different almost everywhere.

Sockets are a large part of the story that changed this. After sockets, networked UNIX systems began to look broadly consistent. We arrived at a more standardized model of network access.

Prior versions of BSD for PDP-11 minicomputers, dating back to 1978, had been released to the research community worldwide on tape: 30 copies of the code for version 1, and 75 copies for version 2. The system was released under a licence issued on behalf of ‘the Regents of the University of California’, and it carefully limited liability and user rights. You received the code in the post on a reel of tape.

If you wanted to update your code, the Regents required continuity of the people signing the licences. This caused problems, as academic roles often shifted between department members in ways the Regents’ lawyers did not anticipate.

When you received an operating system like this on tape, it consisted of a linear series of recordings. Each was denoted by an ‘End of Transmission’ (EOT) marker, which you could skip to reach the next block. In effect, a stream of bytes was read in a fixed format.

To begin, you were provided with minimal hex code to enter by hand at a switch console. This depended on your computer architecture. The code bootstrapped by reading the first tape block into memory, after which you jumped into memory to run it as a bootstrap loader.

Entering the hex meant setting switches across a 16-bit field — up or down, on or off — checking them against a printed listing, and then committing them to memory one address at a time. It was slow and error-prone. The true end-of-tape marker was a silver label that triggered a photoelectric diode to stop the tape motor.

After loading the bootstrap loader, you could format a disk and unpack tape archive (TAR) data from the tape onto it. This encoded all operating system files onto the local disk. The process took most of a day. If you needed to recompile the system, for example, to add device drivers, it could take two or three days. Despite this, many people accepted the cost to gain access to a UNIX system.

Version 4.2BSD shipped with several significant changes. These included bug fixes, an improved filesystem quota method, and symbolic links — which initially puzzled users accustomed to hard links. Alongside these was the Berkeley sockets networking system, developed under contract from the Defence Advanced Research Projects Agency (DARPA). At the time, it wasn’t clear how significant this was.

Before sockets

Before this, access to network services on UNIX relied on programs such as cu or tip. These acted as terminal emulators, sending characters over serial ports to modems. Many early modems were acoustic couplers attached to telephone handsets using Velcro — one part was a microphone, the other a speaker. You connected by dialling the phone.

Tools like the Unix-to-Unix Copy Program (UUCP) used scripts that called cu or similar tools to establish connections, then transferred data. Even using cu was slow. Terminal types in tools such as the vi editor (a BSD innovation by Bill Joy, later a co-founder of Sun Microsystems) reduced screen updates to suit slow links.

UUCP was how we sent mail, read network news, and received (small) files. For much of the research community, it effectively was the network. Others used IBM BITNET or systems such as the UK Science and Engineering Research Council Network (SERC), later JANET (Joint Academic Network), which operated over X.25 data networks.

Sockets and the UNIX file model

Sockets changed all this. They provided a simple, consistent way to connect to ARPANET systems. Crucially, they reused an existing UNIX abstraction — the file descriptor. In simple terms, a socket behaved like a file.

By adopting the UNIX file descriptor model, almost any program that wrote to a file or read a file could be converted to read and write to the network. Back-porting UUCP to work over ARPANET was not particularly hard, and convenient programs like FTP for file transfer, Telnet for online access, and a back-end for the SMTP mail system to talk to the UNIX Sendmail service (another feature of the BSD UNIX system) followed very rapidly. In a remarkably short space of time, almost everything that could talk to sockets had been written to talk to sockets, or some kind of shim program that talked to sockets for you.

Everything ‘just worked’. Or, in the case of the first release of 4.2BSD, it actually didn’t work.

Part of the problem was that most recipients of the 4.2BSD tape had no access to ARPANET. At the time, ARPANET was limited to a small group of US universities and research institutions, with only a few connections in Europe and Asia via satellite. Most sites lacked any network using ARPANET protocols. For example, the university I worked at had Ethernet, but most machines connected to it via serial links rather than directly. We were fortunate to have two Virtual Address Extension (VAX) systems on Ethernet, but one ran VAX/VMS and did not yet include the ARPANET networking code.

Sockets were ‘run’ by connecting them to UNIX-domain sockets, which resembled the existing pipe mechanism. Pipes behaved like special files; they appeared in the filesystem but contained no disk data, and reads depended on writes from another process. To test sockets, you could write C code that connected to one of these local pipes. However, the system was still buggy — our first attempt crashed UNIX. As shipped, the sockets library couldn’t actually communicate with anything.

From experiment to standard

Sockets were not the only candidate interface to the ARPANET protocols. AT&T Bell Labs was developing its own model for network I/O called ‘streams’, released as STREAMS (the capitalization apparently mattered, tied to AT&T’s growing inclination to patent or copyright anything with potential value). Like sockets, STREAMS presented an interface that closely resembled file I/O, making it highly approachable for C programmers already comfortable with working with files.

In practice, however, STREAMS was far less accessible. Its emergence coincided with a legal dispute between AT&T and BSD. As a result, the university regents became more cautious about distributing tapes, while AT&T itself grew increasingly wary of releasing its code to the wider world. Sockets, by contrast, had already arrived and were readily available.

Bill Joy’s new company, Sun Microsystems, soon exploded onto the market with a challenger to the VAX as the default computing platform, this time built around the Motorola 68000 CPU. These machines ran UNIX, specifically, BSD 4.2 and its successors, and so came with the sockets system available out of the box. Here was a desktop-class computer — a fast, high-resolution display, a full UNIX environment, Ethernet built in, and working sockets code from the moment it booted. What was not to love?

DEC responded in this market with the release of ULTRIX, built on progressively smaller VAX systems. ULTRIX drew heavily on BSD UNIX, or at least incorporated significant elements of it, and thus included sockets. One by one, major manufacturers abandoned their proprietary operating systems or introduced forms of UNIX compatibility, and in doing so acquired sockets code.

Even AT&T, while developing what became System V as a commercially ubiquitous version of UNIX, adopted sockets in its networking code. The marketplace of ideas had already decided; despite the appealing qualities of the streams model, networking meant sockets.

From that point on, progress came from many directions. Sun’s Network File System (NFS), built on UDP sockets, became widely adopted. At the same time, shim layers emerged to drive increasingly affordable Ethernet cards for IBM PCs, exposing socket abstractions to Windows environments. In effect, network protocol development settled around the TCP/IP and UDP/IP stack, accessed through sockets. Since then, large-scale innovation has mostly taken the form of refinement — improving performance, or adapting to IPv6 — until the arrival of QUIC, which reimagines session services over UDP and sidelines TCP. And yet, even QUIC ultimately writes to a UNIX socket.

Sockets took over the world.

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.