On 22-Nov-22 04:23, Daniel Stenberg via curl-library wrote:
Yes. Of course, it depends on how robust a check is desired. This comes up often enough that it's worth a few words.On Tue, 22 Nov 2022, Dipak B via curl-library wrote:How can an Windows application integrated with libcurl find out reliably and quickly if the machine has any kind of network connectivity?Further there can be situations were Wifi network is available but Internetconnection / link is not working.In such a situation how does one find if Internet connection is availableusing libcurl?If you by "network connectivity" mean "connectivity to a known HTTP server you have reasonable expectations to exist and respond", then you can just do a HEAD request to that server with a reasonably short timeout and check that it succeeds.If you want to check something more fine-grained than so, then maybe libcurl is not the right answer for you. libcurl is a transfer library, not a network connectivity check library.
The simplest, quickest, least resource-intensive and preferred technique for determining connectivity is ping. (not a curl function). This doesn't establish a connection or require any user-mode resources. It may, however, be blocked by people who falsely consider it an attack vector. For any host run by sane people, it's the tool of choice. You need to know your host.
If the goal is to determine whether a service is up, you need to know something about the service. You could make a small request (e.g. http HEAD, or IMAP STATUS or ...). This may require authentication and certainly takes more resources and is vastly slower. But you get more information. But, maybe not enough. E.g. a HTTP server may be a front end for a cluster, and your request may be routed based on what resource you request. E.g. HEAD may be handled by a front-end cache, while POST may go to a different - possibly down - server. And different POSTs may go to different servers. And then there are cache misses... Finally, "HEAD succeeds" - that says that the specific resource exists. HEAD failing with a 404 could indicate that the server is up, but the resource is no longer served. That "failure" may be considered a "success" with respect to connectivity.
In addition, nothing prevents a service from going down between the time that your test passes and your real request arrives.
Conversely, the lack of connectivity now says nothing about whether there will be connectivity a few seconds - or days - from now. A few days may be fine for a license activation - but weeks may require another approach. Seconds may be too long for a security system. Weeks may be expected when your host is on Mars during solar conjunction.
If the goal is to determine whether the network connectivity is what you expect, timing a ping sequence, or traceroute may help. But if you mean application connectivity, you need to talk to the application. Not just an application - the one you are inquiring about. HTTP being up is at best a weak predictor of SMTP, or SVN, or SIP...
The bottom line: You need to define what "connectivity" means to your application and how many resources you are willing to invest in getting an answer. Much like filesystem permission checks, the only robust way to determine if a system is up is to try your transaction. Anything else is an approximation, which might be "good enough". Or might not.
Simple question, but no universally simple answer. Timothe Litt ACM Distinguished Engineer -------------------------- This communication may not represent the ACM or my employer's views, if any, on the matters discussed.
OpenPGP_signature
Description: OpenPGP digital signature
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
