cURL / Mailing Lists / curl-library / Single Mail


Re: Multi-threading and name resolution issues

From: Daniel Stenberg <>
Date: Fri, 5 Aug 2011 00:56:18 +0200 (CEST)

On Wed, 3 Aug 2011, Jay Sastry wrote:

Please don't top-post.

> But, I do want to know more about the connection cache libcurl internally
> may (or may not) maintain.

libcurl has both a connection cache and a resolver cache. Existing connections
will be kept in the connection cache after use for possible later re-use.
Resolved addresses will be kept in the DNS cache for faster lookups for a
while after the resolve.

> I want my program to be fault tolerant to certain errors, so I intercept the
> CURL_COULDNT_CONNECT error and reset the handle. I would like to know why my
> program cannot recover from this error after doing a curl_easy_duphandle. I
> am able to connect to the server outside of my program without any problem.

That seems odd. Does it have a single IP or a DNS name that resolves to

> Should I do curl_easy_init instead of curl_easy_duphandle?

It doesn't matter. The connection cache only caches working connections and
first only _after_ a working request has been performed.

> Incidentally, I connect to two different web servers, I have not noticed any
> connection drop to the local server, but connection always drops to the
> server that is on a different subdomain.

CURLE_COULDNT_CONNECT is not what I would call a "dropped connection". It is
failed TCP handshake that libcurl initiated.

> I am investigating all components in the middle between the end points to
> track down the root cause, but I still expect my program to recover from
> such errors after resetting the handle.

I don't. As CURLE_COULDNT_CONNECT indicates such a major problem that is
outside libcurl's realms I don't see how any kind of reset of libcurl will
make that problem go away.

Can you explain to me why it would?

List admin:
Received on 2011-08-05