On Sat, Jan 25, 2014 at 11:24 PM, Daniel Stenberg <[email protected]> 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
