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

41–50 of 86 posts

Re: Hooray for the Sockets Interface

#41

Post by actionfromafar »

jchw wrote: post #37
actionfromafar wrote: post #34

Earlier quoted context omitted.

3, fds should have been UUIDs

fds should have been IPv6 addresses. I will not elaborate on why or how.

It's such a common problem to write to a stale file descriptor. It may be closed which is fine, at least you will have an obvious error. But what's much worse is when the stale descriptor actually works, because something else in the program opened a new fd and your stale descriptor is not stale anymore, it just points at something unexpected.

Opaque handles are often a blessing.

Maybe UUID would be overkill (it certainly would have been back in the day of 16-bit unix machines) but something fairly large would have helped a lot.

Even just incrementing and rolling over a 16-bit value would have helped, instead of situations such as closing stdout and stderr, opening a file, and now random error logs sprinkle into your PDF or whatever.

Yes, "you are holding it wrong", but it should be hard to "hold it wrong", not easy.

Re: Hooray for the Sockets Interface

#42

Post by asveikau »

UltraSane wrote: post #11
asveikau wrote: post #7

Earlier quoted context omitted.

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.

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.

Imagine if handling that were a kernel feature completely hidden from you and there was no way to replace it in user mode, or even have visibility into its failure modes. I'd say that's worse.

Re: Hooray for the Sockets Interface

#43

Post by UltraSane »

asveikau wrote: post #42
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.

Imagine if handling that were a kernel feature completely hidden from you and there was no way to replace it in user mode, or even have visibility into its failure modes. I'd say that's worse.

Telling the socket the IDENTITY of the host you want to reach and abstracting away all the details of how to reach it is exactly what the missing TCP/IP sessions layer is supposed to do. By tightly coupling the session layer to explicit Layer 3 network routing parameters (IP addresses), the classic socket API failed to separate a host's identity from its physical location.

Re: Hooray for the Sockets Interface

#44

Post by jchw »

actionfromafar wrote: post #41
jchw wrote: post #37

Earlier quoted context omitted.

fds should have been IPv6 addresses. I will not elaborate on why or how.

It's such a common problem to write to a stale file descriptor. It may be closed which is fine, at least you will have an obvious error. But what's much worse is when the stale descriptor actually works, because something else in the program opened a new fd and your stale descriptor is not stale anymore, it just points at something unexpected. Opaque handles are often a blessing. Maybe UUID would be overkill (it cert…

Joking aside I pretty much agree with this. Windows NT Object handles work pretty well. I assume they are pointers of some kind under the hood, but either way a machine word is probably large enough as it seems unlikely you would ever need to handle more open handles than you have bytes of addressable memory.

Re: Hooray for the Sockets Interface

#45

Post by asveikau »

UltraSane wrote: post #43
asveikau wrote: post #42

Earlier quoted context omitted.

Imagine if handling that were a kernel feature completely hidden from you and there was no way to replace it in user mode, or even have visibility into its failure modes. I'd say that's worse.

Telling the socket the IDENTITY of the host you want to reach and abstracting away all the details of how to reach it is exactly what the missing TCP/IP sessions layer is supposed to do. By tightly coupling the session layer to explicit Layer 3 network routing parameters (IP addresses), the classic socket API failed to separate a host's identity from its physical location.

Questions of identity are established at a higher level in user mode by TLS. Pushing all that into the other side of the kernel interface again seems not great.

Re: Hooray for the Sockets Interface

#46

Post by drdexebtjl »

zbentley wrote: post #40
drdexebtjl wrote: post #36

Earlier quoted context omitted.

That’s true for HTTP. TCP does not require that the act of connecting must be pure, so you cannot indiscriminately apply Happy Eyeballs at the socket API level.

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…

I agree. But we couldn’t have possibly guessed this in the 80s.

Instead we converged on a very simple primitive that makes no such assumptions and can be composed into a wider variety of high level abstractions in user space.

Re: Hooray for the Sockets Interface

#47

Post by kelnos »

cyberax wrote: post #5

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

I don't think that's the reason IPv6 adoption has been slow. It's because ISPs and telcos and data centers and everyone else are slow to upgrade hardware and software, because they don't care about it and because it costs money (money that doesn't get them more money from their customers), not because it's hard.

Re: Hooray for the Sockets Interface

#48

Post by adrian_b »

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…

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 something better than these 3 (starting with System V "poll" and with POSIX AIO, and then with various incompatible approaches in Solaris, FreeBSD and Linux), but none were good enough and most were seriously inferior to methods of doing asynchronous I/O that existed in some IBM and DEC operating systems decades earlier.

In my opinion, only io_uring has finally solved the problem of multiplex asynchronous I/O in Linux, and in a manner much better than in all older operating systems. I consider all the many older alternatives that exist for liburing as obsolete.

Re: Hooray for the Sockets Interface

#49

Post by UltraSane »

asveikau wrote: post #45
UltraSane wrote: post #43

Earlier quoted context omitted.

Telling the socket the IDENTITY of the host you want to reach and abstracting away all the details of how to reach it is exactly what the missing TCP/IP sessions layer is supposed to do. By tightly coupling the session layer to explicit Layer 3 network routing parameters (IP addresses), the classic socket API failed to separate a host's identity from its physical location.

Questions of identity are established at a higher level in user mode by TLS. Pushing all that into the other side of the kernel interface again seems not great.

https://en.wikipedia.org/wiki/Locator/Identifier_Separation_...

I've used this in networks and it enables amazingly easy endpoint mobility.

Re: Hooray for the Sockets Interface

#50

Post by adrian_b »

inigyou wrote: post #27
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.)

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

Mechanisms equivalent with the overlapped I/O of Windows NT (1993) already existed 30 years earlier, e.g. in IBM OS/360 and PL/I (1964/1965).

The main features that were better in Windows NT than in the UNIX-derived operating systems were inherited from the DEC VAX/VMS operating system (1978) (e.g. WaitForMultipleObjects) and a part of them had been inherited from the even earlier operating system DEC RSX-11M (1974-11) (Dave Cutler also had a major role in those operating systems, so there is nothing surprising about this; Microsoft had to pay a big compensation to DEC, on the order of $ 100M, for the features that were obviously taken from the DEC operating systems).

UNIX was very simplified in comparison with the operating systems that were used on bigger computers, and for some things its derivatives never caught up with those older systems, except after 2000. Only "futex" (2002) and "io_uring" (2019) have advanced the state of the art clearly beyond what already existed for AIO on the IBM mainframes around 1964/1966.

Post reply on HN