3 ms·

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 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 3mo 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 3mo 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.
  - inigyou 3mo ago
    Linux will still revert to cookies when exceeding a certain number of half open connections, preventing DoS.
cyberax 3mo ago
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.

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 3mo 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 3mo 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.
- inigyou 3mo ago
  Linux will still revert to cookies when exceeding a certain number of half open connections, preventing DoS.

cyberax 3mo ago

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.