5 ms·

https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ A DNS name can have a LOT of A record

https://blog.ipspace.net/2009/08/what-went-wrong-socket-api/ 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.

jruohonen 3mo ago
> This is a severe limitation. Rather, it is a feature.
- UltraSane 3mo ago
  How so?
  - jruohonen 2mo ago
    > 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.
    - UltraSane 2mo ago
      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.
drdexebtjl 3mo ago
A socket has to pick one, but your application doesn’t. You can hedge your bets and open a connection and send data to _all_ of them, and pick whichever returns faster. This of course requires you to know about the application-layer protocol. For HTTP, you need to restrict this strategy to GET methods, for example. Hence why it can’t be part of the socket interface. You can always build higher level abstractions on top of sockets if you need them.
- cyberax 3mo ago
  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".
  - drdexebtjl 3mo ago
    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.
    - zbentley 3mo ago
      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 quickly if they don't want to use a connections. Lots of servers/load balancers aren't well-tuned to force-close connections if the first byte doesn't arrive within a short time.
      - drdexebtjl 2mo ago
        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.
      - cyberax 2mo ago
        > 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.
zbentley 3mo ago
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 the user. DNS timeouts should be surfaced granularly and differently from e.g. TCP SYNACK timeouts. Once a TCP stream is open, if a novice user opened it conceptually to a domain rather than an address, there's no intuitively correct answer to what happens if the domain's resolution changes while the socket's connected.
- inigyou 2mo ago
  When it was written I don't think they had DNS. Maybe they had hosts files maybe not.
asveikau 3mo ago
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.
- UltraSane 3mo ago
  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.
  - asveikau 3mo ago
    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.
    - UltraSane 2mo ago
      https://en.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol https://en.wikipedia.org/wiki/Locator/Identifier_Separation_... I've used this in networks and it enables amazingly easy endpoint mobility.

jruohonen 3mo ago

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

UltraSane 3mo ago
How so?
- jruohonen 2mo ago
  > 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.
  - UltraSane 2mo ago
    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.

drdexebtjl 3mo ago

A socket has to pick one, but your application doesn’t. You can hedge your bets and open a connection and send data to _all_ of them, and pick whichever returns faster. This of course requires you to know about the application-layer protocol. For HTTP, you need to restrict this strategy to GET methods, for example. Hence why it can’t be part of the socket interface. You can always build higher level abstractions on top of sockets if you need them.

cyberax 3mo ago
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".
- drdexebtjl 3mo ago
  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.
  - zbentley 3mo ago
    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 quickly if they don't want to use a connections. Lots of servers/load balancers aren't well-tuned to force-close connections if the first byte doesn't arrive within a short time.
    - drdexebtjl 2mo ago
      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.
    - cyberax 2mo ago
      > 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.

zbentley 3mo ago

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 the user. DNS timeouts should be surfaced granularly and differently from e.g. TCP SYNACK timeouts. Once a TCP stream is open, if a novice user opened it conceptually to a domain rather than an address, there's no intuitively correct answer to what happens if the domain's resolution changes while the socket's connected.

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

asveikau 3mo ago

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.

UltraSane 3mo ago
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.
- asveikau 3mo ago
  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.
  - UltraSane 2mo ago
    https://en.wikipedia.org/wiki/Locator/Identifier_Separation_Protocol https://en.wikipedia.org/wiki/Locator/Identifier_Separation_... I've used this in networks and it enables amazingly easy endpoint mobility.