Hooray for the Sockets Interface
jruohonen
19 points
14 comments
July 29, 2026
Related Discussions
Found 5 related stories in 374.0ms across 15,236 title embeddings via pgvector HNSW
- One interface, every protocol clevengermatt · 47 pts · April 15, 2026 · 56% similar
- Show HN: Socket to Me, a static file server that runs in the browser markjivko · 13 pts · June 22, 2026 · 53% similar
- Zero-Cost POSIX Compliance: Encoding the Socket State Machine in Lean's Types ngrislain · 32 pts · March 25, 2026 · 47% similar
- IPv6 is the only way forward quaintdev · 48 pts · April 07, 2026 · 46% similar
- IPv8 doener · 13 pts · May 14, 2026 · 46% similar
Discussion Highlights (5 comments)
serious_angel
> 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... > > UUCP was how we sent mail, read network news, and received (small) files. For much of the research community, it effectively was the network... > > Sockets changed all this. > > Source: https://blog.apnic.net/2026/07/28/hooray-for-the-sockets-interface So much has changed... yet so much has not... All are pure marvels and based on dear miracles...
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
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.
UltraSane
The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.
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.)