cURL / Mailing Lists / curl-library / Single Mail


Re: curl_multi reuse connection problem

From: comain chen <>
Date: Fri, 18 Feb 2011 15:13:40 +0800

Thanks Daniel, with your hint I rechecked my issue, the root course
turns out to be
my application is closing persistent sockets during CURL_POLL_REMOVE.

Best regrads,

On Thu, Feb 17, 2011 at 8:11 PM, Daniel Stenberg <> wrote:
> On Thu, 17 Feb 2011, comain chen wrote:
>> 1. When using persistent connections, is there a reliable way to detect
>> whether the reused connection is still alive?
> Yes, and libcurl does it in two ways: first it checks if the socket has
> turned writable which would mean that it died. Then, it takes a special
> precaution in case the first operation on the re-used socket fails and
> re-creates the connection if it does.
>> I think there is no way to do so.
> Why not?
>> Therefore, the transfer over a reused connection can fail at all possible
>> stages (i.e. the reused connection is suddenly dad)
> No. A persistent connection can only validly get disconnected between two
> usages. It cannot disconnect during a request without that being an actual
> error.
>> 2. If the above is true,  all states in curl_multi_runsingle should
>> check for this case and make sure to retry a new fresh connection to
>> recover.
> But it isn't true so we don't.
>> This caused my problem, I am using mutli to connect to several http
>> servers which does not favor persistent connection and closed the connection
>> immediately after response.
> Then it also signals that in the response, and even if doesn't signal it but
> simply closes it anyway, closing the connection after a full response
> shouldn't cause a problem.
>> When a later request comes, it is possible that an old dead connection is
>> reused and caused failure in various stages.
> No. When a request is started it is in the start stage(s), not "in various
> stages", so it can only legitimately fail there and not later on during the
> request's life time.
> --
>  /
> -------------------------------------------------------------------
> List admin:
> Etiquette:

List admin:
Received on 2011-02-18