Commenting below ...
On 1/19/22 2:51 PM, Dmitry Karpov via c-ares wrote:
> Infact, happyeyeballs itself doesn't always do parallel connection
attempts, its an implementation-defined delay before also attempting
the next address in the list.
In case of Happy Eyeballs, a delay between IPv4 and IPv6 connections
is constant and typically relatively short – 200-300ms.
But non-functional IPv6 name servers in the server list may create
dynamic delays in connection establishment which can be very large.
By default, c-ares uses 5s timeout per name server, so it may take 5s
and more (if several IPv6 name servers are in the list) to get to the
connection Happy Eyeballs thus taking much more than expected 200-300ms.
It would be assumed as part of this patch set, this timer would be reduced.
> It would be much easier to stay closer to happy eyeballs and just
sort the dns server list using prior result success/fail (even upfront
sorting using some algorithm to interleave ipv6/ipv4 in a pattern
would help,
> maybe with using logic such as from RFC6724 sec 2.1 like we do in
ares_getaddrinfo for returned addresses, but instead of the
nameservers themselves).
Yes, of course, it is possible that c-ares client can implement some
kind of name server sorting/filtering logic outside of c-ares and just
pass a list of “good” name servers to c-ares, but in this case it has
to be more involved into the name resolution business than it would be
desired.
I wasn't suggesting this be outside of c-ares, I was talking about
implementing this inside of c-ares as a simpler alternative to your
proposal.
-Brad
--
c-ares mailing list
c-ares@lists.haxx.se
https://lists.haxx.se/listinfo/c-ares
