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: H3/QUIC flow control/buffering problem and suggestion
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Wed, 11 Jan 2023 08:22:42 +0100 (CET)
On Tue, 10 Jan 2023, Dmitry Karpov via curl-library wrote:
> It would be great if all QUIC backends implemented such functionality and
> provided API to tune it. Otherwise, we would need to implement such
> "background buffering" in libcurl code wrapping that backend to match TCP
> "background" performance which H1/H2 have.
I'm not convinced this design difference is going to be important in the end
but I don't have any data or proof to back that up. But also, doing such
"background buffering" is going to be difficult for QUIC backends unless they
introduce threads for that purpose, and if they do they get new thread-related
challenges instead. Which the best design is for performant h3 client-side
transfers, I cannot tell.
As I don't plan on writing my own quic/h3 library we are left using the ones
that exist, however their APIs work.
I believe msh3 works similar to the way you describe while quiche and ngcpt2
do not.
> And as H3 in libcurl is moving toward production-ready state, it is
> something to think about.
Performance is not going to be a focus in the work of removing the
experimental label, but we should of course always keep an eye on that and
make sure that we keep polishing the internals to make curl transfer data as
fast as we can.
Date: Wed, 11 Jan 2023 08:22:42 +0100 (CET)
On Tue, 10 Jan 2023, Dmitry Karpov via curl-library wrote:
> It would be great if all QUIC backends implemented such functionality and
> provided API to tune it. Otherwise, we would need to implement such
> "background buffering" in libcurl code wrapping that backend to match TCP
> "background" performance which H1/H2 have.
I'm not convinced this design difference is going to be important in the end
but I don't have any data or proof to back that up. But also, doing such
"background buffering" is going to be difficult for QUIC backends unless they
introduce threads for that purpose, and if they do they get new thread-related
challenges instead. Which the best design is for performant h3 client-side
transfers, I cannot tell.
As I don't plan on writing my own quic/h3 library we are left using the ones
that exist, however their APIs work.
I believe msh3 works similar to the way you describe while quiche and ngcpt2
do not.
> And as H3 in libcurl is moving toward production-ready state, it is
> something to think about.
Performance is not going to be a focus in the work of removing the
experimental label, but we should of course always keep an eye on that and
make sure that we keep polishing the internals to make curl transfer data as
fast as we can.
-- / 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 2023-01-11