Hooray for the Sockets Interface

jjruohonen about 10 hours ago 26 commentsRead Article on blog.apnic.net

⚡ Community Insights

Discussion Sentiment

60% Positive

Analyzed from 828 words in the discussion.

Discussion (26 Comments)Read Original on HackerNews

inigyou•17 minutes ago

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.

Taniwha•about 9 hours ago

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

nickdothutton•about 2 hours ago

While TCP/IP was open source and not controlled by any 1 vendor, quite a few companies made good money from selling TCP/IP stacks and won themselves billion dollar valuations in the process[1][2]. Of course this was during a time when Microsoft saw no point in including an IP stack with their OS, or indeed much point in connecting to the Internet at all! Some of the younger readers may find these things hard to believe.

[1] https://en.wikipedia.org/wiki/FTP_Software [2] https://en.wikipedia.org/wiki/NetManage

pjmlp•about 6 hours ago

Same story with UNIX and C "success".

Everything else was commercial, while by being prevented to sell UNIX, AT&T was fine with giving its source code to universities for a symbolic price for sending the tapes, and the Lion's book.

It changed quite fast the moment AT&T was allowed to claim ownership, however just like with IBM and PC clones, AT&T could no longer take control over UNIX.

jchw•about 7 hours ago

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•17 minutes ago

Windows NT had overlapped IO decades before Linux. The Microsoft kernel team were alright.

__d•about 5 hours ago

The Plan9 network API is an interesting successor to all of STREAMS, streams, and sockets.

serious_angel•about 9 hours ago

    > 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...

cyberax•about 9 hours ago

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.

inigyou•15 minutes ago

there is no protocol specific name resolution. getaddrinfo tells you which type of socket you need to connect to the remote endpoint!

dmitrik•about 2 hours ago

agree they are horrible especially if you want to chase the bug

UltraSane•about 8 hours ago

The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.

asveikau•about 8 hours ago

I disagree with this. Separating lookup from connect(2) or sendmsg(2) is cleaner. If an application doesn't care about the difference, most people are using higher level APIs built on top anyway, and most of those will provide a quick way to hide DNS details from you.

UltraSane•about 7 hours ago

https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/

A DNS name can have a LOT of A records associated but a socket has to pick one. This is a severe limitation.

drdexebtjl•about 6 hours ago

A socket has to pick one, but your application doesn’t.

You can hedge your bets and open a connection and send data to _all_ of them, and pick whichever returns faster.

This of course requires you to know about the application-layer protocol.

For HTTP, you need to restrict this strategy to GET methods, for example.

Hence why it can’t be part of the socket interface.

You can always build higher level abstractions on top of sockets if you need them.

jruohonen•about 7 hours ago

> This is a severe limitation.

Rather, it is a feature.

drdexebtjl•about 7 hours ago

Absolutely not.

You can have sockets without DNS. You can pick whatever strategy you want when there are multiple A records. You can use SRV records instead. And most importantly imo, it mirrors the listening API.

cyberax•about 3 hours ago

Raw addresses could have been an advanced option, rather than a requirement for every program.

GoblinSlayer•about 2 hours ago

Unix sockets kinda already connect by name.

UltraSane•about 2 hours ago

Exactly

lelanthran•about 7 hours ago

By who? I haven't seen this argument before.

UltraSane•about 7 hours ago

https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/

ReactiveJelly•about 6 hours ago

Wouldn't this add a ton of complexity for anything that extends DNS, like DoH, DoT, VPNs, firewalls, etc., and you'd still need to connect by IP for LAN connections or P2P?

Cause what you're asking is not just to do the regular DNS lookup inside `connect`, but to have the OS manage roaming and continuously updating DNS while the connection stays up?

I don't know about that. I don't know. That's a lot of complexity deep in the kernel and ossified.

I'm happy with the QUIC solution that allows you to migrate IPs and it's all userspace. It would be very hard to evolve a network protocol that had to be crammed into 3+ different kernels.

apengwin•about 9 hours ago

Go bears!