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.

>> 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.

-- 
  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html