> If you're not terribly far away and each transfer mostly saturates the pipe,
> doing them serially is not going to be much different than parallel in the
> grand total.
> Multiplexing should still be slightly faster since you won't get punished by
> the RTT gaps and slow-starts that serial
As you asked, here is my wish list based on some discissions in the group!
- Provide the "system" layer functionality.
In short, the "system" functionality API will allow to change the default
options assigned to handles, intercept option setting calls and provide options
that are aligned
On Fri, 10 Feb 2023, Jeroen Ooms wrote:
Ah ok that is better than I thought. I was under the impression that it
would immediately start with 6 connections, even before considering
multiplexing.
There is also CURLOPT_PIPEWAIT that you can use to make libcurl prefer
multiplexing to starting
On Thu, Feb 9, 2023 at 1:31 PM Daniel Stenberg wrote:
>
> On Thu, 9 Feb 2023, Jeroen Ooms wrote:
>
> > OK, I had expected multiplexing to replace the need for
> > multi-connections.
>
> It does up to the point where the connection is "full" of streams and you ask
> for even more transfers. Then
> Am 09.02.2023 um 23:37 schrieb Daniel Stenberg via curl-library
> :
>
> On Thu, 9 Feb 2023, Fabian Keil via curl-library wrote:
>
>> In the mean time I'll keep an eye on the curl commits to see if anyone beats
>> me to it ...
>
> Here's some brainstorming.
>
> We could start out
If you want to say congratulations, share a curl related memory or otherwise
celebrate this historic event in text, this is the thread for you.
=> https://github.com/curl/curl/discussions/10465
--
/ daniel.haxx.se
| Commercial curl support up to 24x7 is available!
| Private help, bug
