Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: How to check if machine has network connectivity using libcurl api reliably?
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: David Woodhouse via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 23 Nov 2022 11:10:27 +0000
On Tue, 2022-11-22 at 20:32 +0000, Dmitry Karpov via curl-library wrote:
> If your use dual-stack libcurl, then you probably will need to run
> two "connectivity" tests - one for "IPv4 only" mode and the other for
> dual-stack "IPv6/IPv4".
> That's because you may have issues with IPv6 when IPv4 is working
> well.
>
In my experience it's been more common recently to see it the other way
round — IPv6 works fine, while Legacy IP is not working. You definitely
need to allow for both scenarios. Don't be one of those applications
which fails when Legacy IP is down, while everything else just
continues to work over IPv6.
> In this case, you have only "IPv4 connectivity" and thus need to make
> your dual-stack applications use "IPv4 only" mode.
You shouldn't need to do that for yourself. If a target host has
multiple IP addresses, libraries like curl should automatically try
them *all* in order of preference without the *application* code having
to get involved.
> (Of course, if you decide that your applications always use IPv4,
> then you need to run only "IPv4 connectivity" tests and explicitly
> set "IPv4 only" mode in your apps).
I'd definitely not recommend that.
Even if your server is stuck in the 20th century and only supports
Legacy IP, you may find that client devices are on IPv6-only networks
using NAT64. So a successful connection might be seen by the *server*
as running over Legacy IP, while the client believes it's using IPv6.
If I tether to my mobile phone over a USB cable, that's precisely the
connectivity mode I get.
So especially don't limit *clients* to Legacy IP, if they're mobile
applications or even devices.
I have devices in my collection which Just Work over NAT64 despite the
actual creators of those devices having no idea that they're living in
the 21st century. They didn't think about IPv6 at all, but the
underlying OS and libraries all just do the right thing, and
connectivity to their Legacy-IP-only service just works anyway.
Don't go out of your way to *break* that.
Received on 2022-11-23
Date: Wed, 23 Nov 2022 11:10:27 +0000
On Tue, 2022-11-22 at 20:32 +0000, Dmitry Karpov via curl-library wrote:
> If your use dual-stack libcurl, then you probably will need to run
> two "connectivity" tests - one for "IPv4 only" mode and the other for
> dual-stack "IPv6/IPv4".
> That's because you may have issues with IPv6 when IPv4 is working
> well.
>
In my experience it's been more common recently to see it the other way
round — IPv6 works fine, while Legacy IP is not working. You definitely
need to allow for both scenarios. Don't be one of those applications
which fails when Legacy IP is down, while everything else just
continues to work over IPv6.
> In this case, you have only "IPv4 connectivity" and thus need to make
> your dual-stack applications use "IPv4 only" mode.
You shouldn't need to do that for yourself. If a target host has
multiple IP addresses, libraries like curl should automatically try
them *all* in order of preference without the *application* code having
to get involved.
> (Of course, if you decide that your applications always use IPv4,
> then you need to run only "IPv4 connectivity" tests and explicitly
> set "IPv4 only" mode in your apps).
I'd definitely not recommend that.
Even if your server is stuck in the 20th century and only supports
Legacy IP, you may find that client devices are on IPv6-only networks
using NAT64. So a successful connection might be seen by the *server*
as running over Legacy IP, while the client believes it's using IPv6.
If I tether to my mobile phone over a USB cable, that's precisely the
connectivity mode I get.
So especially don't limit *clients* to Legacy IP, if they're mobile
applications or even devices.
I have devices in my collection which Just Work over NAT64 despite the
actual creators of those devices having no idea that they're living in
the 21st century. They didn't think about IPv6 at all, but the
underlying OS and libraries all just do the right thing, and
connectivity to their Legacy-IP-only service just works anyway.
Don't go out of your way to *break* that.
-- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
- application/pkcs7-signature attachment: smime.p7s