>> As suggested in many mails on this mailing list, I have tried to
>> solve this using CURLOPT_RESOLVE. I have found two problems:
>
> Let me suggeset yet another way with existing functionality:
>
> Use the share interface, and tell each easy handle that uses those
> host names to use its own share object with its own DNS cache. That
> way, the CURLOPT_RESOLVE setting would (should!) only affect that
> particular DNS cache.
>

Thank you for the suggestion. Using the share interface solves the DNS
problem, but I think that the connection cache problem remains
unsolved because all easy handles in a multi handle use the same
connection cache. Because libcurl looks at the hostname when reusing
connections (not at the IP address), an existing connection to a
"wrong" host may get reused.

What about adding the connection cache to the share object? The SSL
session IDs are already part of it, so adding the connection cache
seems reasonable.

> The drawback is of course that the handles now use one DNS cache
> each and don't benefit from the previous resolves from the other
> handles involved.

For me, that's OK. Of course, a CURLOPT_RESOLVE that only affects one
single easy handle would be better :-)

Regards,
Michael

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2015-05-28