--- title: Hooray for the sockets interface | daily.dev description: In 1983, BSD 4.2 introduced the Berkeley sockets model, a pivotal moment in networking history. Sockets reused the UNIX file descriptor abstraction, making... canonical: https://daily.dev/posts/hooray-for-the-sockets-interface-txukw5lm6 twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Hooray for the sockets interface | daily.dev og:description: In 1983, BSD 4.2 introduced the Berkeley sockets model, a pivotal moment in networking history. Sockets reused the UNIX file descriptor abstraction, making... og:url: https://daily.dev/posts/hooray-for-the-sockets-interface-txukw5lm6 og:image: https://api.daily.dev/og/posts/TxuKW5lm6.png og:image:alt: Hooray for the sockets interface og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Hooray for the sockets interface **[Hacker News](https://daily.dev/sources/hn)** · 8 min read · 0 upvotes · 0 comments ## Summary In 1983, BSD 4.2 introduced the Berkeley sockets model, a pivotal moment in networking history. Sockets reused the UNIX file descriptor abstraction, making network I/O as simple as file I/O and enabling rapid adoption of ARPANET protocols. The piece traces the pre-sockets era of UUCP and acoustic modems, the initial buggy 4.2BSD release, competition from AT&T's STREAMS model, and how Sun Microsystems and others cemented sockets as the universal networking interface. From NFS to QUIC, virtually all network communication still flows through sockets today. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Community take How the wider developer community reacted, aggregated from 1 discussion and 92 comments across hackernews (as of 2026-07-29). **TL;DR:** The community broadly agrees that the BSD socket API was a pragmatic winner over alternatives like STREAMS, but has significant technical criticisms around its tight coupling of IP addresses to connections, poor async I/O primitives, and the resulting drag on IPv6 adoption and Happy Eyeballs standardization. **Sentiment:** 30% positive · 45% mixed · 25% skeptical **The case for** - Sockets won out over over-engineered or proprietary alternatives (STREAMS, X.25, SNA) partly because the implementation was open source and freely available. - The simple, composable primitive allows higher-level abstractions to be built in userspace without burdening the kernel. - TCP/IP's open nature meant no single vendor could lock others out or charge per-packet, enabling broad adoption. - io_uring is seen as finally solving the long-standing async I/O problem in Linux. **The pushback** - The socket API couples connections to a single IP address, hindering multi-address DNS resolution, Happy Eyeballs, MPTCP, and IPv6 adoption. - Non-blocking I/O semantics are fragmented and inconsistent across fd types (O_NONBLOCK, select, poll, epoll, etc.). - File descriptors are small integers that recycle, making stale-fd bugs easy to introduce and hard to catch. - Happy Eyeballs was standardized criminally late (2012), and the socket API's one-connection-one-address model is blamed for slowing IPv6 rollout. - There is no standard way to introspect or migrate TCP connection state (e.g., sequence numbers) across the socket API. **By community** - hackernews (mixed): Commenters appreciate sockets as a pragmatic, composable primitive that beat worse alternatives, but raise substantive criticisms about IP-address coupling, async I/O fragmentation, fd reuse bugs, and the socket API's role in delaying IPv6/Happy Eyeballs adoption. **Hottest debate:** Whether DNS name resolution should be integrated into the socket connect call (with the OS managing multi-address selection and Happy Eyeballs) or kept strictly separate in userspace. **Open questions** - Could a kernel-level Happy Eyeballs or multi-address connect have meaningfully accelerated IPv6 adoption, or would it have introduced worse ossification? - Is there a practical path to a socket-like API that separates host identity from IP address without the complexity concerns raised about VPNs, DoH, and firewalls? - Will QUIC's userspace migration support be sufficient to overcome the one-connection-one-address legacy, or does the kernel API need to change? **Highlights** > 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. > — [cyberax on hackernews · 3 comments](https://news.ycombinator.com/item?id=49093099) > I'd actually say that the original sin of the socket API was taking DNS in higher-level connect methods at all. Users should have to separate the act of address lookup from the act of opening a connection every time (and could write the 5loc utility function to hide that split if they want). I say that not out of purity concerns, but because of how DNS and TCP work. DNS multirecord selection (or not) should be up to the user. DNS timeouts should be surfaced granularly and differently from e.g. TCP SYNACK timeouts. Once a TCP stream is open, if a novice user opened it conceptually to a domain rather than an address, there's no intuitively correct answer to what happens if the domain's resolution changes while the socket's connected. > — [zbentley on hackernews · 1 comments](https://news.ycombinator.com/item?id=49098852) > 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.) > — [jchw on hackernews · 3 comments](https://news.ycombinator.com/item?id=49093516) > Honestly, I think that it is _the_ reason. IPv6 is a terrible protocol, but it could have worked. The problem was that the early IPv6 migration strategies all focused on getting IPv6 connectivity to clients as fast as possible (like 6to4). And once you got that IPv6, a lot of stuff just stopped working. It became all-or-nothing, and the option to just disable IPv6 and fix all the issues has always been there. Happy Eyeballs was standardized criminally late, in 2012. For some reason, the idea that a connection can be something tentative was not a part of the mindset at all. I'm guilty of that as much as everyone else, I remember spending a lot of time working on connection roaming for 3G/WiFi switching. > — [cyberax on hackernews](https://news.ycombinator.com/item?id=49101614) > I'm the network admin for a small ISP that hasn't deployed IPv6 yet. We do have ARIN IPv6 space, but we also have thousands of customers who do not know what that is or care about it either. Twice in twenty years now we have had a customer ask about it, and we have offered to work with them to help pilot support through our network (since if they have a need then that need could act as a standard against which to measure support) but always within a day they simply find some other way to satisfy their need without IPv6. "Get more money from their customers" aside, we do still have a duty to prioritize the needs of our customers, and I'm not pulling budget away from initiatives to improve availability or increase bandwidth or lower latency simply to chase a buggy moving target technology with no light at the end of the tunnel by way of material improvement for our customers. No "killer app". <1% marketing draw if you advertise it as a feature. Nobody's connection gets faster, or higher uptime, instead you just get more complicated support tickets when some website hasn't configured their AAAA records correctly or when some third party's IPv6 support (be that a site online or a home router or an application on the user's laptop) ruins a connection which works fine once the client disables IPv6 support on their end. I would be overjoyed if the tech actually worked as a drop-in replacement, because that is a crazy amount of addressing space. I would be overjoyed if it were actually backwards compatible instead of a mishmash of dual stack and/or CGNAT nonsense. I would be overjoyed if the originally planned path MTU discovery and IPSEC support got off the ground, but those both died in horrible ugly ways. As it is, it has picked up enough steam that some time over the next 15 years we will see a tipping point where the incentives to switch finally benefit all parties and the non-mobile industry starts to fall in line. Where customers actually begin to benefit directly and it becomes worth prioritizing this tech above what they currently perceive as more vital. Where a great enough percentage of our middle-mile and last-mile tech finally support it that we can survive migrating wholesale away from the vendors that do not. And where many of the hellacious pain points of trying to support it today will have been further sanded down and be less damaging to power through. But I said something similar ten years ago and while the needle has moved since then it hasn't moved as far as I would have liked. > — [HappMacDonald on hackernews](https://news.ycombinator.com/item?id=49100940) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=49092754) · 45 points · 92 comments ## Similar posts on daily.dev - [How can you not be romantic about UNIX domain sockets?](https://daily.dev/posts/how-can-you-not-be-romantic-about-unix-domain-sockets--sox4kolgg) · Lobsters · 0 upvotes · 0 comments - [Beyond Localhost: An Engineer’s Guide to Unix Domain Sockets](https://daily.dev/posts/beyond-localhost-an-engineer-s-guide-to-unix-domain-sockets-w0utmm2sx) · Towards Dev · 15 upvotes · 0 comments - [AT&T sued Berkeley over 186 lines of Unix code, and the delay handed the market to Linux](https://daily.dev/posts/at-t-sued-berkeley-over-186-lines-of-unix-code-and-the-delay-handed-the-market-to-linux-oyosqjqqo) · XDA Developers · 1 upvotes · 0 comments - [user.\* xattrs On Sockets Merged For Linux 7.1 As Sought By GNOME & systemd Developers](https://daily.dev/posts/user-xattrs-on-sockets-merged-for-linux-7-1-as-sought-by-gnome-systemd-developers-ivpo78f8u) · Phoronix · 1 upvotes · 0 comments - [Why are you \(still\) using OpenBSD?](https://daily.dev/posts/why-are-you-still-using-openbsd--q3u9wc9hu) · Hacker News · 1 upvotes · 0 comments --- Tags: [#networking](https://daily.dev/tags/networking), [#unix](https://daily.dev/tags/unix) [View this post on daily.dev](https://daily.dev/posts/hooray-for-the-sockets-interface-txukw5lm6) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Hooray for the sockets interface","url":"https://daily.dev/posts/hooray-for-the-sockets-interface-txukw5lm6","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/hooray-for-the-sockets-interface-txukw5lm6"},"datePublished":"2026-07-29T05:41:28.807Z","dateModified":"2026-07-29T23:38:01.164Z","description":"In 1983, BSD 4.2 introduced the Berkeley sockets model, a pivotal moment in networking history. Sockets reused the UNIX file descriptor abstraction, making...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f5d46f9dbba343877b12fcfdba47aeb6?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/f5d46f9dbba343877b12fcfdba47aeb6?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Hacker News","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Hacker News","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/hn","url":"https://daily.dev/sources/hn"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/hooray-for-the-sockets-interface-txukw5lm6","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"networking,unix","timeRequired":"PT8M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Hacker News","item":"https://daily.dev/sources/hn"},{"@type":"ListItem","position":3,"name":"Hooray for the sockets interface"}]} ```