On Sat, Jan 25, 2014 at 11:24 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Sat, 25 Jan 2014, Jonathan Masters wrote:
>
>> 1. If I start a connection and it never connects, how do I know this? It
>> is not like I can get its fd from the curl multi fdset as it's not there.
>
>
> Why would you need an fd to know that? You can only really detect this with
> a timeout or with a failure somewhere. If we rule out the failure somewhere
> which very well may not happen or take a very long time to happen, you're
> left with a timeout.
>
> You can do a timeout two ways: you set one of the libcurl timeout options
> which will cause the transfer to fail if the timeout triggers, or you set a
> timeout yourself and yank out the easy handle if you hit the timeout.
>
> If you do it yourself, you will of course not really know the state of your
> connection (we've discussed exposing the state and we had an experiemental
> patch a while ago) so you then basically just work on "too long time without
> any data delivered" or something like that.

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.

I also tried using curl_multi_fdset to manually check the file
descriptors to see which weren't valid but this was empty.

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?

>
>
>> 2. If I start a connection, with tcp keepalive on, the connection is
>> successful, then for some reason the connection is broken so there are no
>> replies to the tcp keepalives, how do I know the connection is dead before
>> the next request attempt?
>
>
> If nothing is using the connection when it dies, then nothing will detect
> that it is dead until you try to find a connection again the next time (as
> then libcurl will close all connections it finds that are dead).
>
> 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.

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.

So this is why I was trying just an empty send() on the sockets, I
could then tell which CURL connections were dead (due to return code
caused by the KEEPALIVES), but then I got into a big mess,
multi_perform was blocking (so I stuck it in a different thread) and I
soon realised which functions weren't thread safe, due to the
crashing.

Hope this explains a bit more, thank you for your time replying.

Cheers.

> --
>
> / 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-26