Re: How to cleanly close the curl socket in case of multi interface?
Date: Fri, 19 Sep 2014 15:55:48 +0200 (CEST)
On Fri, 19 Sep 2014, nikhil ap wrote:
> CURLOPT_FORBID_REUSE closes the connection immediately and is suited if I
> have to make 1 request / connection. If I have to make 5 requests/
> connection using the same handle, then I cannot use this option because for
> the 2nd request is going to create a new connection which is not what I
That's a might weird use case. Why forcibly close it after the 5th request?
Anyway, set CURLOPT_FORBID_REUSE on the easy handle doing the 5th request (if
you can figure out which that is) and it'll close the connection after its
> To overcome this, I thought I could set CURLOPT_MAXCONNECTS to 1 to force
> the connection cache to be 1 but since I am using multi interface, I used
> CURLMOPT_MAXCONNECTS and set its value to 1.
> This however closed the connection when there were more than one open
> connection and according to the document, "When the cache is full, curl
> closes the oldest one in the cache to prevent the number of open connections
> from increasing" this is a right behavior. Is there a way to avoid this
> behavior? Having easy handle re-using different TCP connection messes with
> my stats.
Right, but you're trying very hard to work around libcurl's features and
impose stupid connection restrictions. libcurl don't expose that level of
control of which connections that are used by which easy handles - it actually
abstracts that way since application mostly don't need to bother.
> I would like to use and re-use each easy handle for just one connection in
> multi-interface enviornment. Is this possible?
I can't say I fully understand what you want. You mean only one single
connection libcurl sets up should be re-used and no other? That's not a setup
easily constructed with libcurl I'd say.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2014-09-19