> https://github.com/curl/curl/blob/f03cc1b7a693b03eddfed2b4c7f8b5fcba9a22e5/lib/asyn-ares.c#L789
Ahh! I was looking into 7.66. curl code, so now I see how ares_getaddrinfo() is
used.
> c-ares details need to be taken to that mailing list.
Yes, I agree that most of this discussion belongs to c-ares mailing list.
But the question remains whether libcurl should always rely on a default DNS
timeout set by c-ares, whatever it is, instead of explicitly setting the "curl"
one?
The concern is that different c-ares versions may have different default
timeouts which can create inconsistent behavior and the snippet:
/* How long we are willing to wait for additional parallel responses after
obtaining a "definitive" one.
This is intended to equal the c-ares default timeout. cURL always uses that
default value. Unfortunately, c-ares doesn't expose its default timeout in
its API, but it is officially documented as 5 seconds.
See query_completed_cb() for an explanation of how this is used.
*/
#define HAPPY_EYEBALLS_DNS_TIMEOUT 5000
makes tight coupling libcurl with c-ares default timeout.
Don't you think that it would be better to break this dependency and have
something like:
#define DEFAULT_DNS_TIMEOUT 2000 // i.e. 2 seconds
...
#define HAPPY_EYEBALLS_DNS_TIMEOUT DEFAULT_DNS_TIMEOUT
...
Curl_resolver_init() {
...
int optmask = ARES_OPT_SOCK_STATE_CB | ARES_OPT_TIMEOUTMS;
...
options.timeout = DEFAULT_DNS_TIMEOUT;
...
}
This simple change will make libcurl DNS timeout consistent regardless if the
default timeout changes in c-ares.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <dan...@haxx.se>
Sent: Monday, December 13, 2021 11:37 PM
To: Dmitry Karpov <dkar...@roku.com>
Cc: Dmitry Karpov via curl-library <curl-library@lists.haxx.se>
Subject: RE: Question about DNS timeout in libCurl
On Mon, 13 Dec 2021, Dmitry Karpov wrote:
> Somehow, I didn't find ares_getaddrinfo() in libcurl code, so you
> probably meant ares_gethostbyname() used by
> Curl_resolver_getaddrinfo() in lib\asyn-ares.c, right?
Line 789:
https://github.com/curl/curl/blob/f03cc1b7a693b03eddfed2b4c7f8b5fcba9a22e5/lib/asyn-ares.c#L789
> my concern was that if we lowered it in c-ares, then it would not be
> aligned with the default 5s value expected from the resolv.conf on
> Linux systems anymore, which might be not a default behavior expected
> from a general-purpose resolver library.
That's a discussion for the c-ares mailing list! My personal view is that
c-ares isn't bound to that timeout value.
> But on the other hand, libcurl doesn't have to follow exactly the
> resolver library constraints (if it is agreed that having 5s default
> in c-ares to match the default value from resolv.conf is a must ), and
> it can use its own default DNS resolver value, which may be lower than
> the c-ares default value.
I think you can drop this line of thinking, switch to ares_getaddrinfo() and
then if there are remaining timeout issues, they will be entirely in the c-ares
camp.
If you insist on doing c-ares the old way, I agree that we can lower the
timeout.
> If it is agreed that changing the c-ares default timeout from 5s to
> some lower value and thus breaking its connection with the default
> value implied by resolv.conf is not a problem, then it is the best
> plan. Especially, if things can be done in parallel, which is very
> important for dual-stack and Happy Eyeballs.
c-ares details need to be taken to that mailing list.
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug fixes, support, ports, new features
| https://curl.se/support.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
