Hooray for the Sockets Interface • Hacker News Board

Re: Hooray for the Sockets Interface

#81

Post by inigyou » Fri, Jul 31, 2026, 2:31 AM UTC

zbentley wrote: post #79

inigyou wrote: post #63

Earlier quoted context omitted.

What would all the other FDs be instead? Like an eventfd or epoll handle, it obviously couldn't be an FD so what would it actually be?

Sorry, what I meant was that FDs that aren’t sockets should be uniformly handled by the async IO syscalls rather than having to parse man pages or trip over EINVALs to figure out the answers to questions like “can I select(2) on a pidfd? Can I O_NOBLOCK a regular on-disk file?”. For a concrete example, I should be able to select/poll/epoll any file descriptor. The multiplexers can short-circuit return for things wher…

Or you throw it all out and do Windows-style overlapped I/O instead.

Re: Hooray for the Sockets Interface

#82

Post by jruohonen » Fri, Jul 31, 2026, 1:43 PM UTC

UltraSane wrote: post #33

jruohonen wrote: post #13

Earlier quoted context omitted.

> This is a severe limitation. Rather, it is a feature.

How so?

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

Re: Hooray for the Sockets Interface

#83

Post by inigyou » Fri, Jul 31, 2026, 2:20 PM UTC

cyberax wrote: post #72

inigyou wrote: post #70

Earlier quoted context omitted.

Why would you implement multiple concurrent connections at the network level instead of making the one single connection work well?

Because there's no way to make that one connection that works well. IPv6 transitional state is fundamentally less stable than IPv4. If you mean that one connection should be able to use multiple address families and addresses, then yes. It would be great, but at a much higher complexity than just making several connections at once and then discarding all but the first succcessful one.

> there's no way to make that one connection that works well

Really? With unlimited ability to tamper with the stuff below the sockets layer, you couldn't make a reliable network? I'm surprised.

Re: Hooray for the Sockets Interface

#84

Post by inigyou » Fri, Jul 31, 2026, 2:21 PM UTC

jchw wrote: post #74

inigyou wrote: post #71

Earlier quoted context omitted.

Then it's libseat and seatd limitations. Why rely on a system that doesn't do what you want? Bypass it and DIY what you actually want.

I personally use a systemd-based distro (NixOS) and logind is able to handle this use case. The point of trying to support libseat was for the sake of non-systemd distros. (Though elogind would probably work too.) I certainly wouldn't DIY this; nothing would support my DIY version, which would defeat the purpose.

The Linux platform gives you full control. If the box you seek doesn't exist, you have to create your own box instead of thinking inside someone else's box that doesn't even do what you need.

Re: Hooray for the Sockets Interface

#85

Post by jchw » Fri, Jul 31, 2026, 8:46 PM UTC

inigyou wrote: post #84

jchw wrote: post #74

Earlier quoted context omitted.

I personally use a systemd-based distro (NixOS) and logind is able to handle this use case. The point of trying to support libseat was for the sake of non-systemd distros. (Though elogind would probably work too.) I certainly wouldn't DIY this; nothing would support my DIY version, which would defeat the purpose.

The Linux platform gives you full control. If the box you seek doesn't exist, you have to create your own box instead of thinking inside someone else's box that doesn't even do what you need.

I'm going to be frank; there is literally no point in replying to me only to not read what I said again. I am running into KDE/GNOME/etc. limitations, not logind. And I both can and have submitted patches to both projects, so I do not need my own box.

Re: Hooray for the Sockets Interface

#86

Post by UltraSane » Sat, Aug 01, 2026, 12:35 PM UTC

jruohonen wrote: post #82

UltraSane wrote: post #33

Earlier quoted context omitted.

How so?

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

Standard TCP maps connections to IP addresses. If your IP changes, the connection drops. A secure cryptographic Session Layer maps connections to your unique device ID. Imagine if the functionality of something like tailscale was actually built into TCP/IP. This is what the missing session layer should have been.