How the Berkeley Sockets Interface Revolutionized Network Access
Hooray for the Sockets Interface
I reflect on the 1983 release of Berkeley Standard Distribution 4.2, which introduced the sockets interface and transformed how we connect to networks. Before this, installing UNIX involved slow, error-prone tape transfers and inconsistent protocols like UUCP. By treating network connections as simple files, sockets unified the system, allowing tools like FTP and Telnet to work seamlessly and paving the way for the modern internet.
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.
- Taniwha
The article kind of misses out on the networking standards of the time - there were many of which TCP and IP were just one, most of the rest were either proprietary (DNA SNA BNA etc) and incompatible, or owned by telecoms who wanted to be able to charge per packet(X.25).
TCP/IP won (IMHO) because the implementation was open source, and because no one was going to make a buck by locking others out (or charging them for the right to build an implementation). Plus there was a working reference implementation available for the taking
- jchw
I have two complaints about sockets:
1, bidirectional sockets probably should've been ≥2 fd's, not 1.
2, non-blocking semantics and poll/select suck.
Can't blame anyone in 1983 for not getting "async I/O" right since we're still struggling; at least now we have some decent answers (like io_uring on Linux.)
- inigyou
Sockets are one of those load-bearing abstractions that you rarely think to peek under - like filesystems, or threads, but sometimes you should work below for extreme performance needs.
- __d
The Plan9 network API is an interesting successor to all of STREAMS, streams, and sockets.
- cyberax
Sockets won over over-engineered monstrosities like STREAMS or X.whatever
And yet, sockets are a terrible interface. They don't provide a way to get the details of the underlying connection for features like migration, checkpointing, or introspection. E.g. there is no way to get the current sequence number for TCP (there is "connection repair" mode now, but it's Linux-specific).
Well, you can say that sockets abstract the low-level details, but then these details hit you in the face when you need to do protocol-specific name resolution.
I now believe that we could have switched to something like IPv6 two decades ago if the socket interface simply allowed binding multiple address families to one socket and handled the name resolution internally.
Sockets also cemented the "one connection - one address" model that is _still_ dragging back the IPv6 adoption. MPTCP or QUIC are still barely supported.