Buy commercial curl support. 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 Daniel himself.
Re: graceful shutdowns coming in 8.9.0
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Stefan Eissing via curl-library <curl-library_at_lists.haxx.se>
Date: Fri, 28 Jun 2024 10:33:33 +0200
With the help of Dan Fandrich I wrote a blog about why RSTs are problematic in TCP: https://github.com/icing/blog/blob/main/every-end-is-a-beginning.md
> Am 27.06.2024 um 23:35 schrieb Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>:
>
> Yes, the fix will definitely help.
> I can see from Stefan's blog that aborted connections will not go through the regular TLS shutdown and thus they will be terminated faster.
>
> This is the right thing to do for aborted connections, I was just thinking about an option when the same approach may be applied for other types of connection closures (too old etc).
> So, while they will not be released as gracefully as they should, their resources may be released potentially faster.
I agree that we should add more control on this for a libcurl application. There are two scenarios:
1. applications that want graceful shutdowns to happen *all the time*, e.g. where the current implementation can only make a last best-effort shutdown.
2. applications that prefer a best effort since they, as you describe, know the risks and have other priorities.
- Stefan
>
> Thanks,
> Dmitry Karpov
>
>
> -----Original Message-----
> From: Daniel Stenberg <daniel_at_haxx.se>
> Sent: Thursday, June 27, 2024 2:05 PM
> To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
> Cc: Dmitry Karpov <dkarpov_at_roku.com>
> Subject: [EXTERNAL] Re: graceful shutdowns coming in 8.9.0
>
> On Thu, 27 Jun 2024, Dmitry Karpov via curl-library wrote:
>
>> In memory constrained and slow systems, like embedded devices, saving
>> a fraction of a second on resource releases (or several hundred
>> milliseconds on slow devices) may be a very important benefit, which
>> will overweigh potential delays in port reuses.
>>
>> That's why I suggested to have an option which would sacrifice faster
>> port reuse but will allow to get faster connection resource release.
>
> This fix also helps for such resource constrained situations. libcurl has always, since before Stefan's fixes, been sloppy at closing (TLS) connections and in situation where you end up with a large volume of closed connections you could find yourself unable to start new connections because of the wait states from the previous ones still lingering.
>
> This fix should make us get faster connection resource release than before, because it helps shut down the TCP correctly so the TCP stack can release the resources quicker.
>
> But we are open to adding options to allow tweaking and customizing of the options, sizes and timeouts involved if people actually run into situations where such are needed.
>
> --
>
> / 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/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
Date: Fri, 28 Jun 2024 10:33:33 +0200
With the help of Dan Fandrich I wrote a blog about why RSTs are problematic in TCP: https://github.com/icing/blog/blob/main/every-end-is-a-beginning.md
> Am 27.06.2024 um 23:35 schrieb Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>:
>
> Yes, the fix will definitely help.
> I can see from Stefan's blog that aborted connections will not go through the regular TLS shutdown and thus they will be terminated faster.
>
> This is the right thing to do for aborted connections, I was just thinking about an option when the same approach may be applied for other types of connection closures (too old etc).
> So, while they will not be released as gracefully as they should, their resources may be released potentially faster.
I agree that we should add more control on this for a libcurl application. There are two scenarios:
1. applications that want graceful shutdowns to happen *all the time*, e.g. where the current implementation can only make a last best-effort shutdown.
2. applications that prefer a best effort since they, as you describe, know the risks and have other priorities.
- Stefan
>
> Thanks,
> Dmitry Karpov
>
>
> -----Original Message-----
> From: Daniel Stenberg <daniel_at_haxx.se>
> Sent: Thursday, June 27, 2024 2:05 PM
> To: Dmitry Karpov via curl-library <curl-library_at_lists.haxx.se>
> Cc: Dmitry Karpov <dkarpov_at_roku.com>
> Subject: [EXTERNAL] Re: graceful shutdowns coming in 8.9.0
>
> On Thu, 27 Jun 2024, Dmitry Karpov via curl-library wrote:
>
>> In memory constrained and slow systems, like embedded devices, saving
>> a fraction of a second on resource releases (or several hundred
>> milliseconds on slow devices) may be a very important benefit, which
>> will overweigh potential delays in port reuses.
>>
>> That's why I suggested to have an option which would sacrifice faster
>> port reuse but will allow to get faster connection resource release.
>
> This fix also helps for such resource constrained situations. libcurl has always, since before Stefan's fixes, been sloppy at closing (TLS) connections and in situation where you end up with a large volume of closed connections you could find yourself unable to start new connections because of the wait states from the previous ones still lingering.
>
> This fix should make us get faster connection resource release than before, because it helps shut down the TCP correctly so the TCP stack can release the resources quicker.
>
> But we are open to adding options to allow tweaking and customizing of the options, sizes and timeouts involved if people actually run into situations where such are needed.
>
> --
>
> / 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/mailman/listinfo/curl-library
> Etiquette: https://curl.se/mail/etiquette.html
-- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-06-28