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: Fri, 23 Sep 2022 23:06:44 +0000
Daniel, I think I am repeating my arguments because some problems that you solution brings in are not addressed.
Even it is very painful to change transfer setup code in all the places to utilize your fix for IPv4 mode, it is at least doable.
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"
The integrated code if it uses dual-stack resolve modes cannot be covered by your solution and connection delays will remain there.
Such code cannot be always modified, especially if it comes in binaries.
I have such code in my applications, and someone else may have such code as well.
Also, how do you suggest to address the problem I outlined in my previous post which your PR introduced?
"This "lazy" approach doesn't allow to create a multi-handle ahead of time to avoid delays on dual-stack connections."
The previous mechanism at least allowed to do that to mitigate the Curl_ipv6works() delays, but not any more after the PR is integrated.
> I have not been convinced that we need to add a new way to say IPv6 doesn't work.
I don't understand why do you call my proposal "a new way"?
It is fundamentally the same old way with an extended option to provide an application-specific way to detect that IPv6 doesn't work on the system.
I guess your PR can be called a "new way" as the penalty for Curl_ipv6works() delays from now on will always be paid for dual-stack connections unless someone will implement this cumbersome mechanism of applying custom "IPv6 works" detection on every dual-stack transfer setup if it is possible (and still have delays when it is not possible to modify the code).
I don't want to argue about simplicity of both approaches, but I think that side-by-side comparison really tells which approach is simpler and easier to use.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Friday, September 23, 2022 3:10 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:
> This would create the same outcome ONLY after your PR fixing IPv4 mode is applied.
Source code changes tend to work like that: they only have an effect after they are actually applied. And my PR is already merged.
I'm sorry, but I think you are repeating your arguments and while I could repeat my arguments again as a reponse I don't think it would drive the discussion forward.
I have not been convinced that we need to add a new way to say IPv6 doesn't work.
Date: Fri, 23 Sep 2022 23:06:44 +0000
Daniel, I think I am repeating my arguments because some problems that you solution brings in are not addressed.
Even it is very painful to change transfer setup code in all the places to utilize your fix for IPv4 mode, it is at least doable.
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"
The integrated code if it uses dual-stack resolve modes cannot be covered by your solution and connection delays will remain there.
Such code cannot be always modified, especially if it comes in binaries.
I have such code in my applications, and someone else may have such code as well.
Also, how do you suggest to address the problem I outlined in my previous post which your PR introduced?
"This "lazy" approach doesn't allow to create a multi-handle ahead of time to avoid delays on dual-stack connections."
The previous mechanism at least allowed to do that to mitigate the Curl_ipv6works() delays, but not any more after the PR is integrated.
> I have not been convinced that we need to add a new way to say IPv6 doesn't work.
I don't understand why do you call my proposal "a new way"?
It is fundamentally the same old way with an extended option to provide an application-specific way to detect that IPv6 doesn't work on the system.
I guess your PR can be called a "new way" as the penalty for Curl_ipv6works() delays from now on will always be paid for dual-stack connections unless someone will implement this cumbersome mechanism of applying custom "IPv6 works" detection on every dual-stack transfer setup if it is possible (and still have delays when it is not possible to modify the code).
I don't want to argue about simplicity of both approaches, but I think that side-by-side comparison really tells which approach is simpler and easier to use.
Thanks,
Dmitry Karpov
-----Original Message-----
From: Daniel Stenberg <daniel_at_haxx.se>
Sent: Friday, September 23, 2022 3:10 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:
> This would create the same outcome ONLY after your PR fixing IPv4 mode is applied.
Source code changes tend to work like that: they only have an effect after they are actually applied. And my PR is already merged.
I'm sorry, but I think you are repeating your arguments and while I could repeat my arguments again as a reponse I don't think it would drive the discussion forward.
I have not been convinced that we need to add a new way to say IPv6 doesn't work.
-- / 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-24