curl / Mailing Lists / curl-library / Single Mail
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

From: Daniel Stenberg via curl-library <>
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...

  | Commercial curl support up to 24x7 is available!
  | Private help, bug fixes, support, ports, new features
Received on 2023-01-10