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@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 <dan...@haxx.se> > Sent: Thursday, June 27, 2024 2:05 PM > To: Dmitry Karpov via curl-library <curl-library@lists.haxx.se> > Cc: Dmitry Karpov <dkar...@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.html
