6 ms·

Hooray for the Sockets Interface

64 points by jruohonen 3mo ago

apengwin 3mo ago
Go bears!
serious_angel 3mo 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...
Taniwha 3mo 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
- pjmlp 3mo 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.
- nickdothutton 3mo 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 https://en.wikipedia.org/wiki/FTP_Software [2] https://en.wikipedia.org/wiki/NetManage https://en.wikipedia.org/wiki/NetManage
  - tomwheeler 3mo ago
    Don't forget Trumpet Winsock [1]. I worked for an ISP at the time that provided it on a floppy disk (along with a newsreader, FTP client, telnet client, and web browser). Although I doubt many customers paid for it, Trumpet Winsock was shareware and very widely used on Windows 3.x. [1] https://en.wikipedia.org/wiki/Trumpet_Winsock https://en.wikipedia.org/wiki/Trumpet_Winsock
cyberax 3mo 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.
- deleted 3mo ago
  [deleted]
- dmitrik 3mo ago
  agree they are horrible especially if you want to chase the bug
- inigyou 3mo ago
  there is no protocol specific name resolution. getaddrinfo tells you which type of socket you need to connect to the remote endpoint!
  - cyberax 3mo ago
    Yes, there is. GAI was standardized in 2002, so it's not a part of the original sockets. And it still does not support Happy Eyeballs.
    - inigyou 3mo ago
      It does return a list of addresses you should try, in preference order, and possibly of different types. I think Happy Eyeballs can't be implemented at that layer. It's inherently involved up to layer 7.
UltraSane 3mo ago
The socket interface using IP addresses instead of DNS names is widely considered to be a major mistake.
- asveikau 3mo 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 3mo ago
    https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ 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.
    - jruohonen 3mo ago
      > This is a severe limitation. Rather, it is a feature.
      - UltraSane 3mo ago
        How so?
        jruohonen 3mo ago
        > How so? Standards as well as all manual pages and other documentation say that getaddrinfo() should be called via a loop by clients. And results show that almost all clients indeed do that. Therefore, on the server-side, you can do round-robin DNS, randomization (as suggested by the post linked), fall-backs, CDN things, and many other things.
        3mo ago
jchw 3mo 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 3mo ago
  Windows NT had overlapped IO decades before Linux. The Microsoft kernel team were alright.
  - jchw 3mo ago
    Windows NT had many things decades before Linux, I've gotten used to it. There are things Windows has that I still sort of wish Linux had, I mentioned one of them just last night (RDP fast user switching/session roaming.) If we're just strictly talking about low level things, another good one would be synchronization primitives, which I guess we now have some of in Linux verbatim at this point, if only for the sake of emulation. (And of course futex2.)
    - inigyou 3mo ago
      I don't think the kernel prohibits fast user switching but you'd have to implement it at the desktop layer too. Think of ctrl-alt-f7, f8 etc. This still works today, you can run X servers as different users on different VT numbers and switch between them. All that's missing is better UI.
      - jchw 3mo ago
        The kernel definitely doesn't, although the VT layer kind of sucks and probably should've never been used to multiplex graphical sessions. (I mean, I get why it was, but oh well.) I was talking about this: https://news.ycombinator.com/item?id=49093002 https://news.ycombinator.com/item?id=49093002 And it winds up being mostly a thing you have to implement in the compositor, but none of them do so far to my knowledge. And of course the same issue applies if you wanted multiple physical seats juggling sessions between them.
__d 3mo ago
The Plan9 network API is an interesting successor to all of STREAMS, streams, and sockets.
inigyou 3mo 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.

64 points by jruohonen 3mo ago

Go bears!

> 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 3mo 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

pjmlp 3mo 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.
nickdothutton 3mo 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 https://en.wikipedia.org/wiki/FTP_Software [2] https://en.wikipedia.org/wiki/NetManage https://en.wikipedia.org/wiki/NetManage
- tomwheeler 3mo ago
  Don't forget Trumpet Winsock [1]. I worked for an ISP at the time that provided it on a floppy disk (along with a newsreader, FTP client, telnet client, and web browser). Although I doubt many customers paid for it, Trumpet Winsock was shareware and very widely used on Windows 3.x. [1] https://en.wikipedia.org/wiki/Trumpet_Winsock https://en.wikipedia.org/wiki/Trumpet_Winsock

cyberax 3mo 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.

deleted 3mo ago
[deleted]
dmitrik 3mo ago
agree they are horrible especially if you want to chase the bug
inigyou 3mo ago
there is no protocol specific name resolution. getaddrinfo tells you which type of socket you need to connect to the remote endpoint!
- cyberax 3mo ago
  Yes, there is. GAI was standardized in 2002, so it's not a part of the original sockets. And it still does not support Happy Eyeballs.
  - inigyou 3mo ago
    It does return a list of addresses you should try, in preference order, and possibly of different types. I think Happy Eyeballs can't be implemented at that layer. It's inherently involved up to layer 7.

UltraSane 3mo ago

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

asveikau 3mo 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 3mo ago
  https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ 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.
  - jruohonen 3mo ago
    > This is a severe limitation. Rather, it is a feature.
    - UltraSane 3mo ago
      How so?
      - jruohonen 3mo ago
        > How so? Standards as well as all manual pages and other documentation say that getaddrinfo() should be called via a loop by clients. And results show that almost all clients indeed do that. Therefore, on the server-side, you can do round-robin DNS, randomization (as suggested by the post linked), fall-backs, CDN things, and many other things.
        3mo ago

jchw 3mo 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 3mo ago
Windows NT had overlapped IO decades before Linux. The Microsoft kernel team were alright.
- jchw 3mo ago
  Windows NT had many things decades before Linux, I've gotten used to it. There are things Windows has that I still sort of wish Linux had, I mentioned one of them just last night (RDP fast user switching/session roaming.) If we're just strictly talking about low level things, another good one would be synchronization primitives, which I guess we now have some of in Linux verbatim at this point, if only for the sake of emulation. (And of course futex2.)
  - inigyou 3mo ago
    I don't think the kernel prohibits fast user switching but you'd have to implement it at the desktop layer too. Think of ctrl-alt-f7, f8 etc. This still works today, you can run X servers as different users on different VT numbers and switch between them. All that's missing is better UI.
    - jchw 3mo ago
      The kernel definitely doesn't, although the VT layer kind of sucks and probably should've never been used to multiplex graphical sessions. (I mean, I get why it was, but oh well.) I was talking about this: https://news.ycombinator.com/item?id=49093002 https://news.ycombinator.com/item?id=49093002 And it winds up being mostly a thing you have to implement in the compositor, but none of them do so far to my knowledge. And of course the same issue applies if you wanted multiple physical seats juggling sessions between them.

__d 3mo ago

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

inigyou 3mo 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.