Honestly, I don't know. It shouldn't grow any larger than buf->max_size
which seems to have a hard limit of 134,217,728 bytes. That said, in
memory constrained systems the TCP receive buffer probably isn't going
to be large enough for this really to make a difference.
Ideally I'd like to set the growth of the buffer to be a function of the
tcp receive buffer. I am getting that information in hpnssh but getting
the extern from channels.c to sshbuf.c is causing a weird link error in
sshkey.c. I haven't nailed that down yet.
Note: resetting the CHAN_SES_DEFAULT_WINDOW to the size in the patch is
just to demonstrate the problem. If you aren't making that buffer bigger
than it's current size (of 2MB) this should never be an issue.
It is an issue for my work in hpnssh because we dynamically adjust SSH's
receive buffer to match auto-tuning TCP receive buffers in order to
maximize throughput.
The main thing is that there was a change in how the buffers are handled
between 8.8 and 8.9 that could, in some cases, end up impacting
performance.
On 5/19/22 2:37 PM, Thorsten Glaser wrote:
On Thu, 19 May 2022, rapier wrote:
then aggressively grow that buffer (4MB at a time)
Does this impact low-memory systems like my SPARCstation
and that old 80486 laptop where growing this much may fail?
bye,
//mirabilos
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
