Re: questions regarding libcurl's multi interface
Date: Thu, 20 Oct 2011 10:08:23 +0200 (CEST)
On Wed, 19 Oct 2011, Jonathon wrote:
Your top-posting makes it very hard to follow what you're talking about. I've
unfolded some of the mysteries to allow people to actually track the subjects.
>>> 2) Is there a way to use the multi interface with several easy handles,
>>> but have them all share the same connection?
> For #2, that's a good question. I'd like to have my client only initiate
> one HTTP connection with the server at all times, but able to submit several
> posts on that connection. After reading your previous comments, I am
> guessing that I probably only need one easy-handle for that and should use
> the HTTP pipelining functionality you referred to.
You don't strictly need pipelining to just do a series of requests over the
same connection. libcurl will do that by default if you just keep doing
requests to the same host. Pipelining will only make it slightly more
efficient, especially in the cases where you have larger RTT.
>>> 3) How would I use the multi interface to keep the connections for my easy
>>> handles alive?
> For #3, once I've submitted all my posts to the server, I'd like to
> keep that connection open so that I can immediately send more posts in
> the future without setting up the connection again. Is there a way to
> do this? (i.e. specify "keep-alive" in the HTTP header).
If you don't kill the multi handle, libcurl will leave the connection alive
for possible future re-use and it'll re-use or re-create the connection at
next request transparently. After one request you just add the handle again
and if that uses the same protocol+host+port then the existing connection will
be used again.
There's not even any need for any keep-alive in a HTTP header since HTTP 1.1
has persistent connections by default.
-- / daniel.haxx.se ------------------------------------------------------------------- List admin: http://cool.haxx.se/list/listinfo/curl-library Etiquette: http://curl.haxx.se/mail/etiquette.htmlReceived on 2011-10-20