 |
 |
A common solution would be [RFC 8305](https://datatracker.ietf.org/doc/html/rfc8305) - the "happy eyeballs" algorithm. This is implemented by browsers to smooth the transition to V6 -- basically, after ~100ms waiting for a IPv6 TCP connection, it starts a second parallel connection attempt with V4 and then use the first connection to complete. Of course, this somewhat tricky concurrency and the extra complexity may only be worthwhile for big applications like a browser. The problem here is that IPv6 is fully functional according to the OS (there's a route to the destination, there's a global IP address, nothing is sending back ICMP packets with "no route to host" to quickly terminate the connection attempt) so the routing configuration error is indistinguishable from the case of "server is unresponsive". Hence, you're hitting the connection timeout before the "second" DNS address is tried. Perhaps a simpler "fail fast" algorithm than Happy Eyeballs is, for hostnames which resolve to `N` addresses, have a "short connection timeout" for the first `N-1` addresses and use the standard connection timeout for the final address. The downside of the latter idea is "complexity kills" for what is ultimately an end-user misconfiguration. The potential upside is that it'd help immensely with cases where the `N` independent addresses represent `N` independent servers -- an unresponsive server (which users aren't at fault for) would be quickly ignored instead of having the client wait for the full timeout window. -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1779#issuecomment-1240672613 You are receiving this because you are subscribed to this thread. Message ID: <[log in to unmask]> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1