On Tue, 12 Aug 2008, Peter Thiess wrote:

> We're investigating the multi interface provided by libcurl to enhance
> transfer rates.

I don't think the multi interface will improve your transfer rates in any
significant way compared to the easy interface...

> We used the examples we found to upload a number of files to one server;
> each file is related to an easy_handle. We observe that a huge number of
> connections are opened each with its own control and data channel.

> After a short while a significant number of connections drop after failure.

You mean failure as in a libcurl bug/misbehavior?

> 1.) Is there a way to limit the number of connections?

Yes, curl_multi_setopt()'s CURLMOPT_MAXCONNECTS option.

> 2.) Is there a way to open one control channel with a number of associated
> data channels while transferring to one server?

No. The control connection will be held "captive" while the data is
transfered, so if you want to re-use the control connection - without causing
a new one to get made - you need to wait for the previous request to end
first.

> 3.) Would a handle pool be an appropriate approach?

That's often what people end up doing, but in recent libcurls the connection
cache is held within the multi handle anyway so the creating and deleting of
easy handles is a very cheap operation that doesn't really hamper performance.
Of course, with a pool style approach you can avoid a few malloc/free
iterations.

> 4.) Are the errors we observe forced by the way we used the multi interface
> or are these likely server related issues?

I would need to get more details to be able to tell. Also you didn't mention
what libcurl version you're using.

-- 
  / daniel.haxx.se