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.
A DNS name can have a LOT of A records associated but a socket has to pick one. This is a severe limitation.
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.
This is even used by browsers, this trick even has a slightly creepy name: "Happy Eyeballs".
TCP does not require that the act of connecting must be pure, so you cannot indiscriminately apply Happy Eyeballs at the socket API level.
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.
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.
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.
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.
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.
Rather, it is a feature.
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.
I've used this in networks and it enables amazingly easy endpoint mobility.