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: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 22 Sep 2022 23:48:58 +0000
> What I cannot understand is how you can implement a working callback for this purpose, called when the connection is to setup, but you cannot set an easy option, done just before the connection is about to get setup.
> Why would one work and not the other?
Not sure if I understand what easy option are you referring to?
Let's say, I have some curl transfer code that sets the "AUTO" option in many different places or it is set by default.
So, with this option set, I want my transfers to use dual-stack when it is available and instantly use IPv4 when IPv6 doesn't work - and thus have the same behavior regardless of whether IPv6-enabled dual-stack libcurl or IPv4 is used.
If I understand what you suggest, then in all the places where the "AUTO" (CURL_IPRESOLVE_WHATEVER) is used, I would need to use something like:
long resolve_mode = my_ipv6_works() ? CURL_IPRESOLVE_WHATEVER : CURL_IPRESOLVE_V4;
curl_easy_setopt(curl, CURLOPT_IPRESOLVE, resolve_mode);
If so, then there are a lot of problems with this approach.
First one is that the "AUTO" will stop being the most efficient mode for dual-stack, because its efficiency will depend on how "IPv6 works" check (provided by "factory default" Curl_ipv6works())
works on some systems (kernels, network configs etc).
And if some curl application accidentally steps on this issue and needs to implement some custom "IPv6 works" mechanism, then it is suggested that after implementing it,
application developer should go through all the places where transfer options are set, explicitly use application specific "IPv6 works" function and explicitly select IPv4 mode if that function returns "false".
Frankly, I think it is just cruel to make developers do that when everything can be solved in just one system level "IPv6 works" callback.
And for me the biggest problem is that I just can't change the code of certain curl-based components used in my application.
They are written by some other developers and closed for any modifications.
So, I will not be able to modify every place where transfers are set in my application just to force it to select the resolve mode to work around the Curl_ipv6works() issues on this specific system.
And when I deploy my application on the platforms where Curl_ipv6works() works OK, it will be silly to do changes like that there.
In other words, it is much easier and cleaner to override how Curl_ipv6works() to adjust to demands of certain systems/scenarios than do checks if "IPv6 works" and change resolve mode in every place where application sets a transfer.
Also, Curl_ipv6works() is called only once per multi-handle, and the "IPv6 works" setting is then used for all easy handles added to that multi-handle.
So, essentially there is no need to do "IPv6 works" for every easy handle - that's also what the system "IPv6 works" callback efficiently allows to avoid.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, September 22, 2022 2:47 PM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
On Thu, 22 Sep 2022, Dmitry Karpov via curl-library wrote:
> That's right. I don't think that it is possible to change the
> Curl_ipv6works() implementation that it will work the same way with
> zero delays for ALL possible kernels/network configurations. And it is
> not possible to change all kernels where some curl application may run
> to make
> Curl_ipv6works() return false with 0ms delay when there are some
> issues with
> IPv6 on kernel levels.
What I cannot understand is how you can implement a working callback for this purpose, called when the connection is to setup, but you cannot set an easy option, done just before the connection is about to get setup.
Why would one work and not the other?
Date: Thu, 22 Sep 2022 23:48:58 +0000
> What I cannot understand is how you can implement a working callback for this purpose, called when the connection is to setup, but you cannot set an easy option, done just before the connection is about to get setup.
> Why would one work and not the other?
Not sure if I understand what easy option are you referring to?
Let's say, I have some curl transfer code that sets the "AUTO" option in many different places or it is set by default.
So, with this option set, I want my transfers to use dual-stack when it is available and instantly use IPv4 when IPv6 doesn't work - and thus have the same behavior regardless of whether IPv6-enabled dual-stack libcurl or IPv4 is used.
If I understand what you suggest, then in all the places where the "AUTO" (CURL_IPRESOLVE_WHATEVER) is used, I would need to use something like:
long resolve_mode = my_ipv6_works() ? CURL_IPRESOLVE_WHATEVER : CURL_IPRESOLVE_V4;
curl_easy_setopt(curl, CURLOPT_IPRESOLVE, resolve_mode);
If so, then there are a lot of problems with this approach.
First one is that the "AUTO" will stop being the most efficient mode for dual-stack, because its efficiency will depend on how "IPv6 works" check (provided by "factory default" Curl_ipv6works())
works on some systems (kernels, network configs etc).
And if some curl application accidentally steps on this issue and needs to implement some custom "IPv6 works" mechanism, then it is suggested that after implementing it,
application developer should go through all the places where transfer options are set, explicitly use application specific "IPv6 works" function and explicitly select IPv4 mode if that function returns "false".
Frankly, I think it is just cruel to make developers do that when everything can be solved in just one system level "IPv6 works" callback.
And for me the biggest problem is that I just can't change the code of certain curl-based components used in my application.
They are written by some other developers and closed for any modifications.
So, I will not be able to modify every place where transfers are set in my application just to force it to select the resolve mode to work around the Curl_ipv6works() issues on this specific system.
And when I deploy my application on the platforms where Curl_ipv6works() works OK, it will be silly to do changes like that there.
In other words, it is much easier and cleaner to override how Curl_ipv6works() to adjust to demands of certain systems/scenarios than do checks if "IPv6 works" and change resolve mode in every place where application sets a transfer.
Also, Curl_ipv6works() is called only once per multi-handle, and the "IPv6 works" setting is then used for all easy handles added to that multi-handle.
So, essentially there is no need to do "IPv6 works" for every easy handle - that's also what the system "IPv6 works" callback efficiently allows to avoid.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Thursday, September 22, 2022 2:47 PM
To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Cc: Dmitry Karpov <dkarpov_at_roku.com>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
On Thu, 22 Sep 2022, Dmitry Karpov via curl-library wrote:
> That's right. I don't think that it is possible to change the
> Curl_ipv6works() implementation that it will work the same way with
> zero delays for ALL possible kernels/network configurations. And it is
> not possible to change all kernels where some curl application may run
> to make
> Curl_ipv6works() return false with 0ms delay when there are some
> issues with
> IPv6 on kernel levels.
What I cannot understand is how you can implement a working callback for this purpose, called when the connection is to setup, but you cannot set an easy option, done just before the connection is about to get setup.
Why would one work and not the other?
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2022-09-23