On Sun, Jan 26, 2014 at 9:52 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Sun, 26 Jan 2014, Jonathan Masters wrote:
>
>> I don't have the source available at the moment so I can't check what I
>> tried, I did set CURLOPT_CONNECTTIMEOUT as an option. I also tried using
>> curl_multi_info_read after the timeout happened but from what I remember,
>> there wasn't any CURLMsg's available, I was hoping there would be one with
>> the CURL easy handle and some error code. I'd have to check this for sure
>> on Monday.
>
>
> If there was no connection made, the CURLOPT_CONNECTTIMEOUT should trigger
> or you've hit a bug.
>
>
>> I also tried using curl_multi_fdset to manually check the file descriptors
>> to see which weren't valid but this was empty.
>
>
> It should only really be empty during name resolves when the stock resolver
> is used. During all other times there is at least one socket involved.
>
>
>> So this comes back to the case of a connection never succeeds (the
>> first time it is created) due to CURLOPT_CONNECTTIMEOUT, how do you
>> know?
>
>
> curl_multi_info_read() has a message for you.

OK so I got rid of all my open/close/socket callbacks and yes - I get
a CURLE_OPERATION_TIMEDOUT message from curl_multi_info_read. *Phew*

>
>
>>> Why would you need to figure that out before next time you want a new
>>> connection?
>>
>>
>> The device I am connecting to is an embedded system with not a lot of
>> resources, it takes a significant amount of time for the TLS connection to
>> it to be established. I have constrains on the time it can take me to issue
>> commands to it via it's REST interface (milliseconds). If I have to wait
>> until the next request to it and the connection is down (lets say it power
>> cycled (no graceful stream tear down)), it would mean I would have to
>> reconnect (taking seconds) then issue the command, well exceeding the time
>> allowed.
>
>
> Ok, but there's just no natural place for libcurl to suddenly check the
> status of another connection. There's also the detail that it is hard to
> know for sure that the connection is really there and alive until you
> actually try to use it.
>
>
>> I could just issue some sort of NOP REST command at intervals but this is
>> a waste of bandwidth for the link and on the limited resources of the device
>> I am connecting to, a TCP KEEPALIVE is a lot more efficient.
>
>
> But... the *reconnection* is what takes time, not closing the old one that's
> deemed dead, isn't it? So just killing off dead connections earlier will not
> gain you very much time for the subsequent re-connect.
>
> I figure we could consider having/adding a way to forcibly scan through
> connections to see if they're dead and if so close them down.
>

That's right, it's the reconnection which takes time, so I want to
reconnect and have the connection setup *before* the next time I need
to make a request. I don't want to only realise the connection is down
at the time the request comes in, which would mean I would have the
delay of connecting and the delay of the request.

In my opinion, I think it would be useful to have a function which
would force a scan through all connections, do a send() and check the
return code (or whatever else is sensible), then generate a CURLMsg
for curl_multi_info_read for dead connections. I'm going to need this
functionality so I'm going to poke around the code today, if you got
any advice it is very much welcome.

Thanks for your time.

>
> --
>
> / daniel.haxx.se
> -------------------------------------------------------------------
> List admin: http://cool.haxx.se/list/listinfo/curl-library
> Etiquette: http://curl.haxx.se/mail/etiquette.html
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2014-01-27