Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Hooray for the Sockets Interface

blog.apnic.net

Post reply on HN
Print view View original

61–70 of 86 posts

Re: Hooray for the Sockets Interface

#61

Post by inigyou »

jchw wrote: post #32
inigyou wrote: post #27

Earlier quoted context omitted.

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

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 o…

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.

Re: Hooray for the Sockets Interface

#62

Post by jchw »

inigyou wrote: post #61
jchw wrote: post #32

Earlier quoted context omitted.

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 o…

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.

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

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.

Re: Hooray for the Sockets Interface

#63

Post by inigyou »

zbentley wrote: post #38
jchw wrote: post #10

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

> non-blocking semantics and poll/select suck. I'd argue that it's not that the semantics suck, it's that there are too many of them. We have O_NONBLOCK, multiple multiplexers (for sane reasons--I don't begrudge 1980s folks for not thinking about fd set size and copy overhead for select(2) either), and others. What's worse, they don't all work with all FDs--not only are regular files not nonblock-able in the same way…

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?

Re: Hooray for the Sockets Interface

#64

Post by inigyou »

jchw wrote: post #62
inigyou wrote: post #61

Earlier quoted context omitted.

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.

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 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 wa…

That's systemd limitations. Who even uses systemd?

Re: Hooray for the Sockets Interface

#65

Post by inigyou »

zbentley wrote: post #39
UltraSane wrote: post #11

Earlier quoted context omitted.

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.

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…

When it was written I don't think they had DNS. Maybe they had hosts files maybe not.

Re: Hooray for the Sockets Interface

#66

Post by inigyou »

cyberax wrote: post #59
zbentley wrote: post #40

Earlier quoted context omitted.

I suppose, but the number of applications for whom a successfully-negotiated bare socket connection (with no TLS or data exchanged) is side-effectful to the point that this causes problems is pretty darn small. I'm sure there are some terrifying counterexamples, but they have to be part of a tiny minority, right? More concerning is the risk of exhausting server socket resources when probe-based connects don't hang up…

> More concerning is the risk of exhausting server socket resources when probe-based connects don't hang up quickly if they don't want to use a connections. TCP connection cookies solved this problem in 90-s! They fell out of use because dedicating a couple MB of RAM to track a few hundred thousand connections is not a big deal anymore.

Linux will still revert to cookies when exceeding a certain number of half open connections, preventing DoS.

Re: Hooray for the Sockets Interface

#67

Post by jchw »

inigyou wrote: post #64
jchw wrote: post #62

Earlier quoted context omitted.

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 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 wa…

That's systemd limitations. Who even uses systemd?

> That's systemd limitations.

It's kind of the opposite, systemd-logind provides better seat management than without. I attempted to implement the same concept using libseat and seatd unsuccessfully though I do not remember exactly what I got caught on. (not in kwin but a toy compositor; I have been at this problem for a little while now.)

That said, most desktop systems have only implemented systemd-logind in a limited way so far that basically just does what the VT system + display manager was already doing, that's what would need to be worked on in order to make this a reality. I was able to accomplish a prototype with only patches to Kwin, kfreerdp and plasma-login-manager, no need to patch systemd-logind or anything like that.

> Who even uses systemd?

Well for one thing, almost all of the major distributions; Ubuntu, Debian, Fedora/RHEL, Arch Linux, NixOS, openSuSE? and of course SteamOS now.

The only major non-systemd Linux distributions I can think of are Alpine Linux and Gentoo. And Android if you wanted to count that, but I think it is special enough to be considered its own OS that just is Linux-based.

Re: Hooray for the Sockets Interface

#68

Post by cyberax »

inigyou wrote: post #60
cyberax wrote: post #55

Earlier quoted context omitted.

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.

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.

Happy Eyeballs was a bad fit for network-level implementation exactly because of sockets. But there's nothing inherently app-level about using multiple probing connections in parallel and then selecting the best one. If the IPv6 authors specified this behavior in the original IPv6 RFCs, we would have taken this behavior for granted.

After all, why would you expect every program under the sun to deal with all the possible network protocols? Who on Earth would expect every software to be rewritten to use IPv6 or SCTP?!? We don't have special open() calls for files on floppy disks or RAM disks, after all.

Sockets already have these "automatic" behaviors. For example, for the connection source address selection. Very few programs explicitly select it, although it's possible.

GAI was a late addition, and it's also awkward in itself.

Re: Hooray for the Sockets Interface

#69

Post by sscaryterry »

adrian_b wrote: post #48
zbentley wrote: post #38

Earlier quoted context omitted.

> non-blocking semantics and poll/select suck. I'd argue that it's not that the semantics suck, it's that there are too many of them. We have O_NONBLOCK, multiple multiplexers (for sane reasons--I don't begrudge 1980s folks for not thinking about fd set size and copy overhead for select(2) either), and others. What's worse, they don't all work with all FDs--not only are regular files not nonblock-able in the same way…

Allready in 1983, 4.2BSD had 3 different attempts at doing multiplexed/asynchronous I/O: Non-blocking I/O: "O_NONBLOCK" with "EWOULDBLOCK" (or "EAGAIN") Signal-driven I/O: "O_ASYNC" with "SIGIO" Synchronous I/O multiplexing: "select()" All 3 had various defects, especially with a large number of concurrent I/O actions. In UNIX-derived operating systems, after 1983 there have been many other attempts to implement some…

This. I'd break-out in a cold sweat if I had to work on this again.

Re: Hooray for the Sockets Interface

#70

Post by inigyou »

cyberax wrote: post #68
inigyou wrote: post #60

Earlier quoted context omitted.

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.

Happy Eyeballs was a bad fit for network-level implementation exactly because of sockets. But there's nothing inherently app-level about using multiple probing connections in parallel and then selecting the best one. If the IPv6 authors specified this behavior in the original IPv6 RFCs, we would have taken this behavior for granted. After all, why would you expect every program under the sun to deal with all the poss…

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