Buy commercial curl support. We
help you work out your issues, debug your libcurl applications, use the API,
port to new platforms, add new features and more. With a team lead by the
curl founder Daniel himself.
Re: Question about upcoming "asyn-ares: connect async" change in 8.20
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 16 Apr 2026 19:40:46 +0000
Hi Stefan,
Thanks for explanations! Now, the direction is clearer, but I think one thing is still worth further discussion.
The Happy Eyeballs v3 proposal document mentions the "resolution time delay":
>>
4.2. Handling DNS Answers Asynchronously
...
The client moves onto sorting addresses and establishing connections once one of the following condition sets is met:
Either:
Some positive (non-empty) address answers have been received AND
A positive (non-empty) or negative (empty) answer has been received for the preferred address family that was queried AND
SVCB/HTTPS service information has been received (or has received a negative response)
Or:
Some positive (non-empty) address answers have been received AND
A resolution time delay has passed after which other answers have not been received.
...
The resolution time delay is a short time that provides a chance to receive preferred addresses (via AAAA records) along with service information (via SVCB/HTTPS records).
This accounts for the case where the AAAA or SVCB/HTTPS records follow the A records by a few milliseconds. This delay is referred to as the "Resolution Delay".
The RECOMMENDED value for the Resolution Delay is 50 milliseconds.
>>
As far as I understand it, the "Resolution Delay" is a waiting period, which directs the client to wait for the preferred family DNS response (IPv6) before trying to
make a connection attempt on a not-preferred one (IPv4) in cases when A response came earlier.
If so, then I guess it becomes a new "Happy Eyeballs timeout" value and thus will probably be controlled by CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS option.
Am I right, or the "Happy Eyeballs timeout" will have a different meaning than the "Resolution Delay"?
I am asking because it is not clear what is the meaning of the "Happy Eyeballs timeout"(HET) with the new approach, as connection attempts now
may start immediately upon receiving DNS response and without waiting for HET to expiry.
I have some concerns about it because I have seen network configurations when AAAA responses may come later than A responses, but it was worth waiting
because IPv6 connections were still faster, and I am afraid that the new mechanism may favor IPv4 connectivity more than before, unless client is provided a mechanism
to tune the "Resolution Delay" and give more slack to IPv6.
Thanks,
Dmitry
-----Original Message-----
From: Stefan Eissing <stefan_at_eissing.org>
Sent: Wednesday, April 15, 2026 11:50 PM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Question about upcoming "asyn-ares: connect async" change in 8.20
Hi,
> Am 16.04.2026 um 00:25 schrieb Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>:
>
> Hi All,
>
> I have a question about the "asyn-ares: connect async" change (https://github.com/curl/curl/pull/21205) in the upcoming 8.20 release.
>
> The PR description says:
> "This PR updates the async DNS resolver behavior (notably the c-ares backend) to issue separate A and AAAA queries and make partial DNS information available earlier, enabling connection attempts to begin as soon as the first relevant DNS response arrives."
>
> I am wondering how this new behavior will affect the Happy Eyeballs for dual-stack?
>
> For example, if the A query result is received earlier than the AAAA query one, does it mean that IPv4 connect attempts will start before IPv6 ones?
Yes.
> Or IPv4 will still have to wait in this case until the HEB timeout expires?
No, the intent of splitting the query is to react to the first incoming response.
> Also, it seems that this change makes it possible to go with a slower IPv4 connection if A response comes faster than AAAA response.
>
> Before this change, the dual-stack race was just between connections,
> and the fastest would win, but now as DNS replies are also part of the "stack" race, it seems possible that a slower stack connection may win if it's DNS reply comes faster.
>
> It would be helpful to get some clarifications how the Happy Eyeballs mechanism will work with this change.
The intent of the changes (and there will be more coming) is to follow the Happy Eyeballs v3 proposal (https://www.ietf.org/archive/id/draft-ietf-happy-happyeyeballs-v3-01.html), at least to an extent that the curl team considers reasonable.
Cheers,
Stefan
>
> Thanks,
> Dmitry Karpov
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Thu, 16 Apr 2026 19:40:46 +0000
Hi Stefan,
Thanks for explanations! Now, the direction is clearer, but I think one thing is still worth further discussion.
The Happy Eyeballs v3 proposal document mentions the "resolution time delay":
>>
4.2. Handling DNS Answers Asynchronously
...
The client moves onto sorting addresses and establishing connections once one of the following condition sets is met:
Either:
Some positive (non-empty) address answers have been received AND
A positive (non-empty) or negative (empty) answer has been received for the preferred address family that was queried AND
SVCB/HTTPS service information has been received (or has received a negative response)
Or:
Some positive (non-empty) address answers have been received AND
A resolution time delay has passed after which other answers have not been received.
...
The resolution time delay is a short time that provides a chance to receive preferred addresses (via AAAA records) along with service information (via SVCB/HTTPS records).
This accounts for the case where the AAAA or SVCB/HTTPS records follow the A records by a few milliseconds. This delay is referred to as the "Resolution Delay".
The RECOMMENDED value for the Resolution Delay is 50 milliseconds.
>>
As far as I understand it, the "Resolution Delay" is a waiting period, which directs the client to wait for the preferred family DNS response (IPv6) before trying to
make a connection attempt on a not-preferred one (IPv4) in cases when A response came earlier.
If so, then I guess it becomes a new "Happy Eyeballs timeout" value and thus will probably be controlled by CURLOPT_HAPPY_EYEBALLS_TIMEOUT_MS option.
Am I right, or the "Happy Eyeballs timeout" will have a different meaning than the "Resolution Delay"?
I am asking because it is not clear what is the meaning of the "Happy Eyeballs timeout"(HET) with the new approach, as connection attempts now
may start immediately upon receiving DNS response and without waiting for HET to expiry.
I have some concerns about it because I have seen network configurations when AAAA responses may come later than A responses, but it was worth waiting
because IPv6 connections were still faster, and I am afraid that the new mechanism may favor IPv4 connectivity more than before, unless client is provided a mechanism
to tune the "Resolution Delay" and give more slack to IPv6.
Thanks,
Dmitry
-----Original Message-----
From: Stefan Eissing <stefan_at_eissing.org>
Sent: Wednesday, April 15, 2026 11:50 PM
To: libcurl development <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: [EXTERNAL] Re: Question about upcoming "asyn-ares: connect async" change in 8.20
Hi,
> Am 16.04.2026 um 00:25 schrieb Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>:
>
> Hi All,
>
> I have a question about the "asyn-ares: connect async" change (https://github.com/curl/curl/pull/21205) in the upcoming 8.20 release.
>
> The PR description says:
> "This PR updates the async DNS resolver behavior (notably the c-ares backend) to issue separate A and AAAA queries and make partial DNS information available earlier, enabling connection attempts to begin as soon as the first relevant DNS response arrives."
>
> I am wondering how this new behavior will affect the Happy Eyeballs for dual-stack?
>
> For example, if the A query result is received earlier than the AAAA query one, does it mean that IPv4 connect attempts will start before IPv6 ones?
Yes.
> Or IPv4 will still have to wait in this case until the HEB timeout expires?
No, the intent of splitting the query is to react to the first incoming response.
> Also, it seems that this change makes it possible to go with a slower IPv4 connection if A response comes faster than AAAA response.
>
> Before this change, the dual-stack race was just between connections,
> and the fastest would win, but now as DNS replies are also part of the "stack" race, it seems possible that a slower stack connection may win if it's DNS reply comes faster.
>
> It would be helpful to get some clarifications how the Happy Eyeballs mechanism will work with this change.
The intent of the changes (and there will be more coming) is to follow the Happy Eyeballs v3 proposal (https://www.ietf.org/archive/id/draft-ietf-happy-happyeyeballs-v3-01.html), at least to an extent that the curl team considers reasonable.
Cheers,
Stefan
>
> Thanks,
> Dmitry Karpov
>
> --
> Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-04-16