On Fri, 29 May 2009 10:41:29 +0200 (CEST), Daniel Stenberg <daniel_at_haxx.se>
wrote:
> On Thu, 28 May 2009, junk_at_igrspace.com wrote:
>
>> I found that when a connection is re-used over easies that had
>> CURLOPT_CONNECT_ONLY set, a curl_easy_getinfo() for CURLINFO_LASTSOCKET
>> fails (returning -1) for the subsequent easy.
>
> 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.

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.

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.

And finally there was http://curl.haxx.se/mail/lib-2009-05/0296.html *a

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. 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.

What do you think of this approach ?

Immanuel
Received on 2009-05-31