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

51–60 of 86 posts

Re: Hooray for the Sockets Interface

#51

Post by HappMacDonald »

kelnos wrote: post #47
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.

I'm the network admin for a small ISP that hasn't deployed IPv6 yet.

We do have ARIN IPv6 space, but we also have thousands of customers who do not know what that is or care about it either. Twice in twenty years now we have had a customer ask about it, and we have offered to work with them to help pilot support through our network (since if they have a need then that need could act as a standard against which to measure support) but always within a day they simply find some other way to satisfy their need without IPv6.

"Get more money from their customers" aside, we do still have a duty to prioritize the needs of our customers, and I'm not pulling budget away from initiatives to improve availability or increase bandwidth or lower latency simply to chase a buggy moving target technology with no light at the end of the tunnel by way of material improvement for our customers.

No "killer app". I would be overjoyed if the tech actually worked as a drop-in replacement, because that is a crazy amount of addressing space. I would be overjoyed if it were actually backwards compatible instead of a mishmash of dual stack and/or CGNAT nonsense. I would be overjoyed if the originally planned path MTU discovery and IPSEC support got off the ground, but those both died in horrible ugly ways.

As it is, it has picked up enough steam that some time over the next 15 years we will see a tipping point where the incentives to switch finally benefit all parties and the non-mobile industry starts to fall in line. Where customers actually begin to benefit directly and it becomes worth prioritizing this tech above what they currently perceive as more vital. Where a great enough percentage of our middle-mile and last-mile tech finally support it that we can survive migrating wholesale away from the vendors that do not. And where many of the hellacious pain points of trying to support it today will have been further sanded down and be less damaging to power through.

But I said something similar ten years ago and while the needle has moved since then it hasn't moved as far as I would have liked.

Re: Hooray for the Sockets Interface

#52

Post by cyberax »

drdexebtjl wrote: post #35
cyberax wrote: post #20

Earlier quoted context omitted.

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

I feel like this wouldn’t be a problem if we had decent APIs for name resolution (separate from sockets) instead. The ones we have suck or are non-standard.

Nope. They have to be coupled for the Happy Eyeballs to work.

Another option is for sockets to accept multiple addresses and address families in "connect" calls, so that only one connection wins.

Re: Hooray for the Sockets Interface

#53

Post by jchw »

adrian_b wrote: post #50
inigyou wrote: post #27

Earlier quoted context omitted.

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

To be fair, I think that was the entire challenge in the first place: the contemporary microcomputers were relatively limited on what they could do, so you couldn't necessarily afford to just do everything mainframes were doing. More importantly, it's not clear you would've wanted to. Having the taste and good sense to know what to "steal" and how to "steal" it was already hard enough work. A lot of good ideas took a while to come over, but a lot of probably bad ideas also never did.

It's an evergreen interesting fact that Dave Cutler took perhaps a bit too much inspiration from prior VMS work to NT, but I also think there's no need to put an asterisk on it anymore than there is UNIX or anything else; it does ultimately stand on its own. Like great artists, great software architects steal.

Re: Hooray for the Sockets Interface

#54

Post by cyberax »

drdexebtjl wrote: post #36
cyberax wrote: post #19

Earlier quoted context omitted.

You absolutely can establish multiple TCP connections for POST methods. You just can't send any _data_. This is even used by browsers, this trick even has a slightly creepy name: "Happy Eyeballs".

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.

That's theoretically true. But I don't know any public Internet-facing apps that care about that.

For non-public networks, sure. For things like TCP-to-RS232 connectors that can only service one connection at a time. Happy Eyeballs needs to be disabled for them, but that's just one socket option.

And if the Happy Eyeballs protocol was standardized earlier, these kinds of apps arguably would have adapted to it.

Re: Hooray for the Sockets Interface

#55

Post by cyberax »

inigyou wrote: post #28
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…

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

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.

Re: Hooray for the Sockets Interface

#56

Post by drdexebtjl »

cyberax wrote: post #52
drdexebtjl wrote: post #35

Earlier quoted context omitted.

I feel like this wouldn’t be a problem if we had decent APIs for name resolution (separate from sockets) instead. The ones we have suck or are non-standard.

Nope. They have to be coupled for the Happy Eyeballs to work. Another option is for sockets to accept multiple addresses and address families in "connect" calls, so that only one connection wins.

No, they don’t. They aren’t coupled today, and applications implementing Happy Eyeballs work perfectly fine on top of sockets and a DNS client.

Re: Hooray for the Sockets Interface

#57

Post by cyberax »

kelnos wrote: post #47
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.

Honestly, I think that it is _the_ reason. IPv6 is a terrible protocol, but it could have worked.

The problem was that the early IPv6 migration strategies all focused on getting IPv6 connectivity to clients as fast as possible (like 6to4). And once you got that IPv6, a lot of stuff just stopped working. It became all-or-nothing, and the option to just disable IPv6 and fix all the issues has always been there.

Happy Eyeballs was standardized criminally late, in 2012. For some reason, the idea that a connection can be something tentative was not a part of the mindset at all.

I'm guilty of that as much as everyone else, I remember spending a lot of time working on connection roaming for 3G/WiFi switching.

Re: Hooray for the Sockets Interface

#58

Post by cyberax »

drdexebtjl wrote: post #56
cyberax wrote: post #52

Earlier quoted context omitted.

Nope. They have to be coupled for the Happy Eyeballs to work. Another option is for sockets to accept multiple addresses and address families in "connect" calls, so that only one connection wins.

No, they don’t. They aren’t coupled today, and applications implementing Happy Eyeballs work perfectly fine on top of sockets and a DNS client.

Well, yeah. And I also can do IPv6 without any of these new-fangled application-level TCP by using raw sockets.

War story: many years ago I was developing a service that runs computational tasks inside containers. That was when K8s didn't work well with cloud providers.

The service was written in Go and worked on AWS. Everything worked fine for me and for our production deployment. Then people started using it with a Python client that used the REST API directly, and for some reason some people couldn't reach it when they were working from home.

Reason: I misconfigured IPv6 on AWS by not enabling the default route, so all IPv6 connections were failing. Go has HappyEyeballs enabled by default, so it worked just fine.

But Python did not have it back then. So people with IPv4-only connectivity (including our office) had no problems. But people with IPv6 were getting connection failures.

Re: Hooray for the Sockets Interface

#59

Post by cyberax »

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…

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

Re: Hooray for the Sockets Interface

#60

Post by inigyou »

cyberax wrote: post #55
inigyou wrote: post #28

Earlier quoted context omitted.

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

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.

Post reply on HN