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: Tue, 10 Jan 2023 09:01:58 +0100 (CET)
On Mon, 9 Jan 2023, Dmitry Karpov via curl-library wrote:
> Exactly! That's why I proposed to use a new "CURLOPT_QUIC_BUFFERSIZE" option
> for that purpose. This option would control QUIC buffering for different
> backends separating it from the CURLOPT_BUFFERSIZE option, which is
> currently used for limiting the max amount of data to be sent in the "write
> callbacks".
The write callback only delivers up to CURL_MAX_WRITE_SIZE bytes per
invocation, and that means 16kB.
> That's right. But the CURLOPT_BUFFERSIZE currently just limits how much data
> Curl sends to the "write callbacks",
Not really. It limits how much data libcurl can accumulate before it calls the
application though. For multiplexing protocols it might be worth having them a
little larger just because how libcurl might need to have to "fill up" data
for many concurrent transfers before the application gets a chance to "drain"
each transfer's buffers.
> Right, I am talking about two separate "buffering" systems - transport layer
> internal buffering (socket buffer etc.) and Curl's reading buffering. In the
> essence, Curl's reading buffering is an intermediate layer between transport
> layer and the end client.
Sure, but we need a lot more than just a proposed name to get such
functionality in place. Perhaps even such a new buffering system could be done
and used without even introducing a new option...
Date: Tue, 10 Jan 2023 09:01:58 +0100 (CET)
On Mon, 9 Jan 2023, Dmitry Karpov via curl-library wrote:
> Exactly! That's why I proposed to use a new "CURLOPT_QUIC_BUFFERSIZE" option
> for that purpose. This option would control QUIC buffering for different
> backends separating it from the CURLOPT_BUFFERSIZE option, which is
> currently used for limiting the max amount of data to be sent in the "write
> callbacks".
The write callback only delivers up to CURL_MAX_WRITE_SIZE bytes per
invocation, and that means 16kB.
> That's right. But the CURLOPT_BUFFERSIZE currently just limits how much data
> Curl sends to the "write callbacks",
Not really. It limits how much data libcurl can accumulate before it calls the
application though. For multiplexing protocols it might be worth having them a
little larger just because how libcurl might need to have to "fill up" data
for many concurrent transfers before the application gets a chance to "drain"
each transfer's buffers.
> Right, I am talking about two separate "buffering" systems - transport layer
> internal buffering (socket buffer etc.) and Curl's reading buffering. In the
> essence, Curl's reading buffering is an intermediate layer between transport
> layer and the end client.
Sure, but we need a lot more than just a proposed name to get such
functionality in place. Perhaps even such a new buffering system could be done
and used without even introducing a new option...
-- / 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-10