Re: How to check if machine has network connectivity using libcurl api reliably?

From: Timothe Litt <litt_at_acm.org>
Date: Tue, 22 Nov 2022 05:42:45 -0500

On 22-Nov-22 04:23, Daniel Stenberg via curl-library wrote:
> 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
>> Internet
>> connection / link is not working.
>>
>> In such a situation how does one find if Internet connection is
>> available
>> using 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.
>
Yes.  Of course, it depends on how robust a check is desired. This comes
up often enough that it's worth a few words.

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.

-- 
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette:   https://curl.se/mail/etiquette.html

Received on 2022-11-22