Re: curl-library Digest, Vol 71, Issue 41
Date: Fri, 29 Jul 2011 23:39:59 +0530
> On Thu, 28 Jul 2011, ajil koshy wrote:
> > I have an https client using libcurl (with openssl) multi APIs.
> > Occasionally, I see that if remote peer application exits, the libcurl
> > client's 'multi-loop' (the one which calls curl_multi_perform repeatedly
> > till running handles reach zero) goes into an infinite loop instead of
> > breaking out. Is this expected behavior?
> Without any kind of timeout set, I figure there's a risk that something
> for what may be perceived as "infinitely".
> But also note that you didn't state what libcurl version or OS you're
I am using libcurl version 7.21.5 on windows.
> > Also, after each curl_multi_perform call, I also check if any errors
> > occurred on the individual transfers using curl_multi_info_read function
> > which case I can exit the loop. I would like to know what is the
> > way to find out if remote peer has disconnected (and thereby error out of
> > the multi-loop) while using libcurl?
> curl_multi_info_read() is the definitive way.
I am already calling curl_multi_info_read after calling curl_multi_perform
(as mentioned earlier). This should probably return some kind of error,
shouldn't it? The problem is that I am observing intermittent behavior here.
In some cases, I see that calling curl_multi_info_read yields a connection
closed error but on some other occasions, the loop just runs on and on.
Another observation is that the call to select () function used to wait on
inbound data returns SOCKET_ERROR if peer application has exited. However, I
cannot use this as a sufficient condition to break out of the multi-loop as
I have observed that select call fails while data transfer is in progress
> > I have come across articles which suggest we can attempt to read from the
> > socket which would but I am not sure of implications of doing this while
> > using libcurl.
> That's a really bad iadea. If you would read from a socket that is still in
> use by libcurl then you will effectively ruin that transfer. Not to mention
> that you would have to make an effort to even get to know the socket in
> first place.
> > Is there any callback I can register for or info I can query in libcurl
> > achieve this?
> You don't need any callback for that, curl_multi_info_read() is all you
> / daniel.haxx.se
> Message: 4
> Date: Thu, 28 Jul 2011 20:39:20 +0200 (CEST)
> From: Daniel Stenberg <daniel_at_haxx.se>
> To: libcurl development <curl-library_at_cool.haxx.se>
> Subject: Re: Problem with file upload using CURLFORM_BUFFER
> Message-ID: <alpine.DEB.2.00.1107282035410.9781_at_tvnag.unkk.fr>
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> On Wed, 27 Jul 2011, Henry Ludemann wrote:
> > The commit in f851f768578dc096c561d57ba07ffd1004d504c0
> > (CURLFORM_STREAM: acknowledge CURLFORM_FILENAME) broke uploading using
> > CURLFORM_BUFFER / CURLFORM_BUFFERPTR.
> Ouch. Thanks for the report. If you want bonus points, try writing up a
> case for it. I'll look at the problem once I get back home next week.
> / daniel.haxx.se
> Message: 5
> Date: Thu, 28 Jul 2011 15:21:59 -0700 (PDT)
> From: Peter <one2001boy_at_yahoo.com>
> To: Pierre Joye <pierre.php_at_gmail.com>, "curl-library_at_cool.haxx.se"
> Subject: Re: compilation in windows
> Content-Type: text/plain; charset=iso-8859-1
> >That's for the CRT linkage, it is usually better to use /MD over /MT,
> >unless one likes to provide updates when a new CRT version is
> Thanks for your information.
> I am testing the examples now, CURLOPT_VERBOSE was set to 0.
> run the code and it will always display the following information:
> " % Total??? % Received % Xferd? Average Speed?? Time??? Time???? Time?
> ???????????????????????????????? Dload? Upload?? Total?? Spent??? Left?
> 100?? 396? 100?? 380? 100??? 16??? 871???? 36 --:--:-- --:--:-- --:--:--??
> is there a way to depress it?
> curl-library mailing list
> End of curl-library Digest, Vol 71, Issue 41
List admin: http://cool.haxx.se/list/listinfo/curl-library
Received on 2011-07-29