> Is that what you're referring to in all cases?
Yes, all my "regressions" and "problems" referrals are for 30+ ms connection
delays caused by Curl_ipv6works() used in the dual-stack IPv6-enabled libcurl.
And these problems and regressions occur when code is migrated from IPv4
libcurl to dual-stack IPv6-enabled one.
I never mentioned any other problems or regressions in this e-mail thread.
> It might in your situation, but it wouldn't in everybody else's.
It will help in my situation, but it might also help in somebody's else case as
well.
There are few points here:
1. These regressions happen for some pretty recent linux kernel versions and
configurations used in embedded software, and somebody else might step on the
same issues as I did when migrating to dual-stack libcurl and try to find a
solution for the same dual-stack issues/regressions.
2. The Curl_ipv6works() is a good default approach, but it is very difficult to
find a "one size that fits all" solution.
That's why I don't propose that libcurl should provide a solution for
everybody which covers all possible scenarios and corner cases.
Instead, I propose that libcurl would provide a way for everyone to solve
these issues if the system calls inside Curl_ipv6works() are causing problems
critical for them.
3. I don't see any other good ways to work around these issues for IPv6-related
resolve modes (CURL_IPRESOLVE_WHATEVER and CURL_IPRESOLVE_IPV6.) except letting
curl application to provides a custom way of detecting if "IPv6 works".
I think that my proposal will provide useful customization for dual-stack curl
applications, and I am not sure that I fully understand your objections like "
It might in your situation, but it wouldn't in everybody else's.".
There are always cases where something will not be good enough, and additional
customization helps to handle such cases.
So, again, I am not proposing some concrete change to the Curl_ipv6works()
which will just help my individual problem.
Instead, I am proposing a dual-stack related customization which will help to
solve issues with the default "IPv6 works" detection that may be very different
from my specific problems, but still critical for someone's else application.
Thanks,
Dmitry Karpov
-----Original Message-----
From: curl-library <[email protected]> On Behalf Of Dan
Fandrich via curl-library
Sent: Wednesday, September 21, 2022 1:53 PM
To: [email protected]
Cc: Dan Fandrich <[email protected]>
Subject: Re: [EXTERNAL] Re: Feature request: provide ability to set a global
callback function telling libcurl if IPv6 works on the system
On Wed, Sep 21, 2022 at 08:19:46PM +0000, Dmitry Karpov via curl-library wrote:
> Daniel's PR fixed the issue only for CURL_IPRESOLVE_V4, but not for
> CURL_IPRESOLVE_WHATEVER and CURL_IPRESOLVE_IPV6.
> Even with his PR, both CURL_IPRESOLVE_WHATEVER and CURL_IPRESOLVE_IPV6 will
> use Curl_ipv6works() and thus face regressions.
I find many of your messages too vague, and I can't tell any more what exactly
are the specific problems that you're still having. They're using terms like
"regressions" and "problem" but I can't tell any more if you're referring to
the 30 msec delay during Curl_ipv6works() or if there are other issues you're
seeing. Is that what you're referring to in all cases?
> Before Daniel's PR, the problem was for all three resolve modes:
> CURL_IPRESOLVE_WHATEVER, CURL_IPRESOLVE_IPV6 and CURL_IPRESOLVE_IPV6
>
> After his PR, the problem remains for two modes:
> CURL_IPRESOLVE_WHATEVER and CURL_IPRESOLVE_IPV6
If Curl_ipv6works() were not called in the CURL_IPRESOLVE_V6 case, would that
solve the issues that are remaining?
> My proposal, in addition to Daniel's PR allows to close the gap and avoid
> connection regressions for all three modes.
It might in your situation, but it wouldn't in everybody else's.
Dan
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
--
Unsubscribe: https://lists.haxx.se/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
