3 ms·

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 detail

by 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.
    - cyberax 3mo ago
      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.
      - inigyou 3mo ago
        Why would you implement multiple concurrent connections at the network level instead of making the one single connection work well?
        cyberax 3mo ago
        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.
        inigyou 3mo ago
        > 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.
kelnos 3mo ago
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.
- HappMacDonald 3mo ago
  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". <1% marketing draw if you advertise it as a feature. Nobody's connection gets faster, or higher uptime, instead you just get more complicated support tickets when some website hasn't configured their AAAA records correctly or when some third party's IPv6 support (be that a site online or a home router or an application on the user's laptop) ruins a connection which works fine once the client disables IPv6 support on their end. 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.

by cyberax 3mo ago

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.
  - cyberax 3mo ago
    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.
    - inigyou 3mo ago
      Why would you implement multiple concurrent connections at the network level instead of making the one single connection work well?
      - cyberax 3mo ago
        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.
        inigyou 3mo ago
        > 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.

kelnos 3mo ago

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.

HappMacDonald 3mo ago
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". <1% marketing draw if you advertise it as a feature. Nobody's connection gets faster, or higher uptime, instead you just get more complicated support tickets when some website hasn't configured their AAAA records correctly or when some third party's IPv6 support (be that a site online or a home router or an application on the user's laptop) ruins a connection which works fine once the client disables IPv6 support on their end. 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.