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.
http/2 multiplexing buffering
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: XSLT2.0 via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 28 Dec 2020 11:19:32 +0100
>> It is still scary to read in libcurl's documentation that when
pausing http/2 libcurl might buffer up to 32MB of data for each transfer!
>> Is there a "SETOPT" to control that?
> Another way to reduce the caching would be to not pause that long
while you read other transfers over the same connection...
When writing a FileSystem (FS) with libcurl (eg curlftpfs), the FS does
not know how long will the "pause" be since it depends on the behaviour
of other application programs using the FS.
At some point the FS might even need to reconnect if it was too long and
the server closed the socket.
> No, but we could make one. The issue is of course that the 32MB is the
window you tell the server you have open, and reducing that window might
have a performance impact.
Thanks. So far I'm fine with the hardcoded value because I have not seen
any "filelockers" use http/2 for the "storage" servers, but preparing
such an option could be useful for the future or for other use cases.
The issue again with FS, is if user applications open 100+ simultaneous
files (soft ulimit is usually 1024), the FS could end up eating
Gigabytes of memory!
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-28
Date: Mon, 28 Dec 2020 11:19:32 +0100
>> It is still scary to read in libcurl's documentation that when
pausing http/2 libcurl might buffer up to 32MB of data for each transfer!
>> Is there a "SETOPT" to control that?
> Another way to reduce the caching would be to not pause that long
while you read other transfers over the same connection...
When writing a FileSystem (FS) with libcurl (eg curlftpfs), the FS does
not know how long will the "pause" be since it depends on the behaviour
of other application programs using the FS.
At some point the FS might even need to reconnect if it was too long and
the server closed the socket.
> No, but we could make one. The issue is of course that the 32MB is the
window you tell the server you have open, and reducing that window might
have a performance impact.
Thanks. So far I'm fine with the hardcoded value because I have not seen
any "filelockers" use http/2 for the "storage" servers, but preparing
such an option could be useful for the future or for other use cases.
The issue again with FS, is if user applications open 100+ simultaneous
files (soft ulimit is usually 1024), the FS could end up eating
Gigabytes of memory!
Cheers
Alain
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
Received on 2020-12-28