On Fri, 21 Feb 2020, Daniel Jeliński via curl-library wrote:
Well then, I'd vote in favor of not allowing pause when CURLMOPT_PIPELINING
is set to anything other than CURLPIPE_NOTHING. I'm not a fan of changes
that may negatively impact performance, as you may guess. And I never used
pause
Well then, I'd vote in favor of not allowing pause when
CURLMOPT_PIPELINING is set to anything other than CURLPIPE_NOTHING.
I'm not a fan of changes that may negatively impact performance, as
you may guess. And I never used pause anyway.
Regards,
Daniel
On Fri, 21 Feb 2020, Daniel Jeliński via curl-library wrote:
Sounds like the problem HPN-SSH tried to solve:
https://www.psc.edu/index.php/hpn-ssh/638 I like their approach, but I'm not
sure how they got hold of the current TCP receive window size; the only
value I could find was receive
Sounds like the problem HPN-SSH tried to solve:
https://www.psc.edu/index.php/hpn-ssh/638
I like their approach, but I'm not sure how they got hold of the
current TCP receive window size; the only value I could find was
receive buffer size, which is not necessarily relevant here.
If you decide to
On Thu, 20 Feb 2020, Daniel Stenberg via curl-library wrote:
But even so, the buffer size might very well be set to smaller sizes than
you'd want the HTTP/2 window size to be. Can we avoid a new option for
window size without having users suffer?
Jay brought the suggestion [1] that we could
