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: Mon, 26 Sep 2022 19:48:29 +0000
> Closed source applications that use libcurl cannot be fixed unless the creators fix their applications. This goes not only for IPv4/IPv6 issues but for all options libcurl provides.
I am not talking about applications like executables. I am referring "components", which may be integrated and run in some "hosting" application.
Such architectures are quite often for embedded designs.
The "hosting" application serves as a system management host (to some extent it may provide OS kind of layer on top of the underlying low-level OS-es like Embedded Linux) which sets memory and network parameters specific for the hardware platform on which it operates and provides secure and optimized environment for other "components" to run.
These components are not "tightly coupled" with the host management application, so they are not aware of any memory or network management which the "host" application is doing for them.
Your proposal for fixing problem with the default "IPv6 works" function is to move the problem from the "system" level to the "client" level and make clients aware of which "platform" (HW, kernel version etc) they may running on and use platform-specific "IPv6 works" function in all places where transfer is set.
But there are fundamental problems with this approach, which makes it not a good solution.
1. What if there are more than 10+ platforms which require platform-specific handling of the "IPv6 works" function?
Then the client code should do some pseudo-code:
if (platform == platform1)
... use platform1 "IPv6 works"
...
if (platform == platform10)
... use platform10 "IPv6 works"
And what if in future the same code needs to run on 10 more platforms? The client code needs to be updated with any new platform then.
2. How to "inject dependency" on platform specific low-level "IPv6 works" function into the client code?
For example, some "components" may be using multiple layers and high-level languages (i.e. JavaScript etc), and the transfer setup code (which is done on some low-level layer)
is not exposed for the upper layers at all.
Such components provide system-agnostic application frameworks, which share the same code for different OSes (i.e. Windows, MacOS, Linux),
and they are also agnostic to which libcurl (single-stack or dual-stack) their lower layer may be using.
So, for such components there will be no way to inject "platform A" specific "IPv6 works" function and modify their transfer setup code on the upper "client" level.
> Because it introduces both a new public API function call plus a new concept of a global callback.
This new public API is proposed only for providing a good and convenient solution for the "system" issues mentioned above.
It is by no means a new way to set the "resolve mode" option for transfers.
On the contrary, it emphasizes that "IPv6 works" is a system setting, not a transfer setting, and it aims to make transfer setup code agnostic to the fact that IPv6 doesn't work on some specific platform.
In other words, why some libcurl-based code should be aware that it is using dual-stack libcurl and on some platform "IPv6 works" check creates unnecessary delays,
and transfer setup code in client code should be modified to handle these platform-specific delays?
If "IPv6 works" is a system setting which depends on platforms where libcurl is running, then it is quite logical to have it as a global callback.
Such approach will allow to avoid any problems with handling platform-specific IPv6 issues in the client code and make client code "loosely coupled" with the system management process running on that platform.
I see the same approach was used for memory management functions, which are also "system" level functionality, so I am not inventing a completely new approach for system-level customization .
I understand your reluctance to add a new public API, document it etc.
But considering benefits it provides for dealing with dual-stack issues on embedded platforms (where a very wide range of linux kernels, including custom builds from SOC vendors), I think it is worth it.
And if documenting, publishing etc is a hassle then can we make it "undocumented API" then?
It is still will be a useful feature to have for folks who are facing issues with the default "IPv6 works" in embedded world?
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Saturday, September 24, 2022 2:16 PM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
On Fri, 23 Sep 2022, Dmitry Karpov wrote:
> But how do you suggest to address the issues with "closed code" as I
> outlined in my previous post?
> " - if you code integrates (or will do that future) some "3rd party"
> components which might be using libcurl and dual-stack resolve modes,
> which you can't modify"
Closed source applications that use libcurl cannot be fixed unless the creators fix their applications. This goes not only for IPv4/IPv6 issues but for all options libcurl provides.
> I don't understand why do you call my proposal "a new way"?
Because it introduces both a new public API function call plus a new concept of a global callback.
Date: Mon, 26 Sep 2022 19:48:29 +0000
> Closed source applications that use libcurl cannot be fixed unless the creators fix their applications. This goes not only for IPv4/IPv6 issues but for all options libcurl provides.
I am not talking about applications like executables. I am referring "components", which may be integrated and run in some "hosting" application.
Such architectures are quite often for embedded designs.
The "hosting" application serves as a system management host (to some extent it may provide OS kind of layer on top of the underlying low-level OS-es like Embedded Linux) which sets memory and network parameters specific for the hardware platform on which it operates and provides secure and optimized environment for other "components" to run.
These components are not "tightly coupled" with the host management application, so they are not aware of any memory or network management which the "host" application is doing for them.
Your proposal for fixing problem with the default "IPv6 works" function is to move the problem from the "system" level to the "client" level and make clients aware of which "platform" (HW, kernel version etc) they may running on and use platform-specific "IPv6 works" function in all places where transfer is set.
But there are fundamental problems with this approach, which makes it not a good solution.
1. What if there are more than 10+ platforms which require platform-specific handling of the "IPv6 works" function?
Then the client code should do some pseudo-code:
if (platform == platform1)
... use platform1 "IPv6 works"
...
if (platform == platform10)
... use platform10 "IPv6 works"
And what if in future the same code needs to run on 10 more platforms? The client code needs to be updated with any new platform then.
2. How to "inject dependency" on platform specific low-level "IPv6 works" function into the client code?
For example, some "components" may be using multiple layers and high-level languages (i.e. JavaScript etc), and the transfer setup code (which is done on some low-level layer)
is not exposed for the upper layers at all.
Such components provide system-agnostic application frameworks, which share the same code for different OSes (i.e. Windows, MacOS, Linux),
and they are also agnostic to which libcurl (single-stack or dual-stack) their lower layer may be using.
So, for such components there will be no way to inject "platform A" specific "IPv6 works" function and modify their transfer setup code on the upper "client" level.
> Because it introduces both a new public API function call plus a new concept of a global callback.
This new public API is proposed only for providing a good and convenient solution for the "system" issues mentioned above.
It is by no means a new way to set the "resolve mode" option for transfers.
On the contrary, it emphasizes that "IPv6 works" is a system setting, not a transfer setting, and it aims to make transfer setup code agnostic to the fact that IPv6 doesn't work on some specific platform.
In other words, why some libcurl-based code should be aware that it is using dual-stack libcurl and on some platform "IPv6 works" check creates unnecessary delays,
and transfer setup code in client code should be modified to handle these platform-specific delays?
If "IPv6 works" is a system setting which depends on platforms where libcurl is running, then it is quite logical to have it as a global callback.
Such approach will allow to avoid any problems with handling platform-specific IPv6 issues in the client code and make client code "loosely coupled" with the system management process running on that platform.
I see the same approach was used for memory management functions, which are also "system" level functionality, so I am not inventing a completely new approach for system-level customization .
I understand your reluctance to add a new public API, document it etc.
But considering benefits it provides for dealing with dual-stack issues on embedded platforms (where a very wide range of linux kernels, including custom builds from SOC vendors), I think it is worth it.
And if documenting, publishing etc is a hassle then can we make it "undocumented API" then?
It is still will be a useful feature to have for folks who are facing issues with the default "IPv6 works" in embedded world?
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Saturday, September 24, 2022 2:16 PM
To: Dmitry Karpov <dkarpov_at_roku.com>
Cc: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
Subject: RE: [EXTERNAL] Re: Feature request: provide ability to set a global callback function telling libcurl if IPv6 works on the system
On Fri, 23 Sep 2022, Dmitry Karpov wrote:
> But how do you suggest to address the issues with "closed code" as I
> outlined in my previous post?
> " - if you code integrates (or will do that future) some "3rd party"
> components which might be using libcurl and dual-stack resolve modes,
> which you can't modify"
Closed source applications that use libcurl cannot be fixed unless the creators fix their applications. This goes not only for IPv4/IPv6 issues but for all options libcurl provides.
> I don't understand why do you call my proposal "a new way"?
Because it introduces both a new public API function call plus a new concept of a global callback.
-- / 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-26