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: Fri, 17 Apr 2026 22:00:12 +0000
> The happy eyeball timeout setting has the same semantics as before, spacing the different connect attempts.
I think the PR is a very good step forward, but there still may be a confusion between the "Resolution delay" and the happy eyeball timeout among Curl users.
Because now we have a notion of the "first connection attempt", which may kind of ignore the happy eyeball timeout and start IPv4 connection after 50ms (resolution delay)
instead of 200ms (happy eyeball timeout) if the name resolution is missing.
Now, we may have two flavors of "first connection attempts":
1. Requires DNS resolution (no entries in the DNS cache) - may start IPv4 connection after 50ms (resolution time) if AAAA reply is not received.
2. No resolution is needed (not expired entries in the DNS cache) - starts IPv4 connection after 200ms (happy eyeball timeout).
So, depending on run-time conditions (i.e. DNS entry expired) we may have two different behaviors:
one that uses the "resolution time" 50ms to start IPv4 connection (and thus ignores the happy eyeball timeout),
and the other uses the "happy eyeball timeout" 200ms to start IPv4 connection.
This may cause problems in certain environments, which rely on the happy eyeball timeout to determine the stack winner.
I think there is probably some flaw in HEBv3 proposal, which doesn't fully consider this aspect.
It assumes that a stack family with the fastest DNS reply will always be the best choice, but that reasoning is not always correct as
the stack family with the fastest reply may have slowest connections.
And client applications that favor connection speed more than the DNS reply times (i.e. video streaming or gaming applications) which download tons of data over the same connection
would prefer to select a family with faster connection speeds rather than with faster DNS replies.
In my view, the right approach would be as follows:
- Always start the happy eyeball timer first, regardless of whether DNS resolution is needed or not.
- Start DNS queries, if needed, and take the reply times for preferred family as part of connection times for the happy eyeball timeout to start family stack connections.
This means that if AAAA reply comes first then we start IPv6 connection right away,
but if A reply comes first, we still wait until happy eyeball timeout expires before we start IPv4 connection.
This approach is consistent with the happy eyeball timeout expectations we have today, and it still gives a chance for faster IPv6 connections to win even if AAAA replies are delayed for more than 50ms.
Ideally, it would be helpful to provide an option to the client which for the first connects would allow to start IPv4 connections either always after the happy eyeball timeout expires or start them after the "resolution time" expires.
Thanks,
Dmitry
-----Original Message-----
From: Stefan Eissing <stefan_at_eissing.org>
Sent: Friday, April 17, 2026 4:50 AM
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
Follow up: DNS resolution delay implemented in https://github.com/curl/curl/pull/21354
> Am 17.04.2026 um 09:06 schrieb Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>:
>
>
>
>> Am 16.04.2026 um 21:40 schrieb Dmitry Karpov <dkarpov_at_roku.com>:
>>
>> 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.
>
> This is an aspect we have not implemented yet. I see your point in regard to AAAA addresses. curl always treated them as the preferred address family. I am hesitant to implement the 50ms delay for HTTPS records right now since they are still rare.
>
> My next iteration will most likely be:
> - if a AAAA answer has been received (positive or negative), continue connecting.
> - without AAAA answer, wait the 50ms before continuing.
>
>>>>
>>
>> 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"?
>
> The happy eyeball timeout setting has the same semantics as before, spacing the different connect attempts.
>
>>
>> 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.html
Date: Fri, 17 Apr 2026 22:00:12 +0000
> The happy eyeball timeout setting has the same semantics as before, spacing the different connect attempts.
I think the PR is a very good step forward, but there still may be a confusion between the "Resolution delay" and the happy eyeball timeout among Curl users.
Because now we have a notion of the "first connection attempt", which may kind of ignore the happy eyeball timeout and start IPv4 connection after 50ms (resolution delay)
instead of 200ms (happy eyeball timeout) if the name resolution is missing.
Now, we may have two flavors of "first connection attempts":
1. Requires DNS resolution (no entries in the DNS cache) - may start IPv4 connection after 50ms (resolution time) if AAAA reply is not received.
2. No resolution is needed (not expired entries in the DNS cache) - starts IPv4 connection after 200ms (happy eyeball timeout).
So, depending on run-time conditions (i.e. DNS entry expired) we may have two different behaviors:
one that uses the "resolution time" 50ms to start IPv4 connection (and thus ignores the happy eyeball timeout),
and the other uses the "happy eyeball timeout" 200ms to start IPv4 connection.
This may cause problems in certain environments, which rely on the happy eyeball timeout to determine the stack winner.
I think there is probably some flaw in HEBv3 proposal, which doesn't fully consider this aspect.
It assumes that a stack family with the fastest DNS reply will always be the best choice, but that reasoning is not always correct as
the stack family with the fastest reply may have slowest connections.
And client applications that favor connection speed more than the DNS reply times (i.e. video streaming or gaming applications) which download tons of data over the same connection
would prefer to select a family with faster connection speeds rather than with faster DNS replies.
In my view, the right approach would be as follows:
- Always start the happy eyeball timer first, regardless of whether DNS resolution is needed or not.
- Start DNS queries, if needed, and take the reply times for preferred family as part of connection times for the happy eyeball timeout to start family stack connections.
This means that if AAAA reply comes first then we start IPv6 connection right away,
but if A reply comes first, we still wait until happy eyeball timeout expires before we start IPv4 connection.
This approach is consistent with the happy eyeball timeout expectations we have today, and it still gives a chance for faster IPv6 connections to win even if AAAA replies are delayed for more than 50ms.
Ideally, it would be helpful to provide an option to the client which for the first connects would allow to start IPv4 connections either always after the happy eyeball timeout expires or start them after the "resolution time" expires.
Thanks,
Dmitry
-----Original Message-----
From: Stefan Eissing <stefan_at_eissing.org>
Sent: Friday, April 17, 2026 4:50 AM
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
Follow up: DNS resolution delay implemented in https://github.com/curl/curl/pull/21354
> Am 17.04.2026 um 09:06 schrieb Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>:
>
>
>
>> Am 16.04.2026 um 21:40 schrieb Dmitry Karpov <dkarpov_at_roku.com>:
>>
>> 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.
>
> This is an aspect we have not implemented yet. I see your point in regard to AAAA addresses. curl always treated them as the preferred address family. I am hesitant to implement the 50ms delay for HTTPS records right now since they are still rare.
>
> My next iteration will most likely be:
> - if a AAAA answer has been received (positive or negative), continue connecting.
> - without AAAA answer, wait the 50ms before continuing.
>
>>>>
>>
>> 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"?
>
> The happy eyeball timeout setting has the same semantics as before, spacing the different connect attempts.
>
>>
>> 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.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2026-04-18