On Sun, 31 May 2009, junk_at_igrspace.com wrote:

>> Can you elaborate a little on what exactly you're trying to accomplish
>> with this?
>
> ok, this application is supposed to perform multiple
> concurrent requests and let the user define
> (1) whether to use SSL or not
> (2) whether to use a proxy or not
> (3) whether to use a libcurl protocol or not
> (4) whether to re-use connections or open a new one for each request
> (5) how many concurrent connections to allow
>
> Seemed like a good libcurl multi-interface candidate to me: (1) and (2) are
> libcurl options. (3) can be accomplished by an external library feeding
> curl_easy_send() and curl_easy_recv(). (4) could be the CURLOPT_FORBID_REUSE
> option. And (5) should be the number of easies added to the multi.

I would say that it sounds like you should use libcurl for all these where the
answer to (3) is "libcurl protocol".

> But i learned that connections are maintained (and re-used) by the multi
> handle. So my approach for (5) does not work. And CURLMOPT_MAXCONNECTS also
> doesn't come into the picture as i only have a single host.

Well, the concurrent connections is easily controlled. Just add as many easy
handles you want connections. And make sure CURLMOPT_MAXCONNECTS isn't higher.

> Then i stumbled upon known bug 63, making (3) incompatible with (4). The
> work-around mentioned for known bug 63 works for just easy handles, not for
> easies added to a multi handle.

Exactly. In fact CONNECT_ONLY is more or less incompatible with the multi
interface as it currently works.

> So instead of having CURLOPT_FORBID_REUSE close connections after perform,
> it could be more interesting to have it prevent libcurl from RE-USING open
> connections.

Yes, but atm there's only this single option. I'd even suggest that
CONNECT_ONLY would imply that behavior. But it's not only a single option on
the outside, it's also a single boolean internally.

> This could allow multiple connections
> to the same host (work-around for known bug 63 and fix for *a).
> One could then set CURLMOPT_MAXCONNECTS close 'old' open connections.

Not exactly. A connection that is CONNECT_ONLY and not closed would need some
new way of getting told that it is now done and over with so that it can get
closed (as it can't be re-used anyway). Simply using CURLMOPT_MAXCONNECTS as
you suggest would make it close connections that are possibly still in use.

And to be honest, I'm not convinced it is worth all the efforts to get libcurl
working with this. It feels like a lot of work to get libcurl to be better at
being a lot less libcurl while I think the effort is perhaps more wisely used
to instead make your app do the non-libcurl stuff better outside of libcurl...

-- 
  / daniel.haxx.se