Buy commercial curl support from WolfSSL. 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
himself.
RE: Question about DNS timeout in libCurl
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 16 Dec 2021 09:04:35 +0100 (CET)
On Tue, 14 Dec 2021, Dmitry Karpov wrote:
> 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?
We also don't set any timeouts for the stock name resolver functions but rely
on their internally used timeouts. I don't think curl has better or more
information than the resolver library so I don't think we can make a better
decision.
How do other common getaddrinfo implementations handle (timeouts for)
non-responding name reservers? It seems like behavior we should be able to
mimick.
> The concern is that different c-ares versions may have different default
> timeouts which can create inconsistent behavior
Yes, but that's more of a feature than a bug. When c-ares fixes problems in
later versions it is a good thing that curl can work with them. "inconsistent
behavior" goes both ways.
> makes tight coupling libcurl with c-ares default timeout.
Yes, but now we're back in "old code" territory and that old way of using
c-ares had more problem than just that timer dependency so I suggest you move
away from that. The "new code" path sets no timeout at all but relies on
c-ares' default.
> options.timeout = DEFAULT_DNS_TIMEOUT;
> This simple change will make libcurl DNS timeout consistent regardless if
> the default timeout changes in c-ares.
If we can't improve c-ares to do this better then I think this is a change to
consider, yes. I want us to first explore fixing this in the resolver code.
Date: Thu, 16 Dec 2021 09:04:35 +0100 (CET)
On Tue, 14 Dec 2021, Dmitry Karpov wrote:
> 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?
We also don't set any timeouts for the stock name resolver functions but rely
on their internally used timeouts. I don't think curl has better or more
information than the resolver library so I don't think we can make a better
decision.
How do other common getaddrinfo implementations handle (timeouts for)
non-responding name reservers? It seems like behavior we should be able to
mimick.
> The concern is that different c-ares versions may have different default
> timeouts which can create inconsistent behavior
Yes, but that's more of a feature than a bug. When c-ares fixes problems in
later versions it is a good thing that curl can work with them. "inconsistent
behavior" goes both ways.
> makes tight coupling libcurl with c-ares default timeout.
Yes, but now we're back in "old code" territory and that old way of using
c-ares had more problem than just that timer dependency so I suggest you move
away from that. The "new code" path sets no timeout at all but relies on
c-ares' default.
> options.timeout = DEFAULT_DNS_TIMEOUT;
> This simple change will make libcurl DNS timeout consistent regardless if
> the default timeout changes in c-ares.
If we can't improve c-ares to do this better then I think this is a change to
consider, yes. I want us to first explore fixing this in the resolver code.
-- / 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.htmlReceived on 2021-12-16