PuTTY semi-bug flow-control-filexfer

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Pre-release · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Be less clever with SSH-2 flow control in PSFTP and PSCP
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: tricky: Needs many tuits.
priority: medium: This should be fixed one day.
fixed-in: r7679 16cbd4f26095627796e2774e0ca43648f9c4c692 2007-08-06 (0.61)

(This wish applies to SSH-2; SSH-1 doesn't provide flow control above TCP's.)

As Peter Gutmann has observed, naive implementations of the SSH-2 sliding window protocol place an arbitrary limit on the throughput of each channel, limiting it to the product of the window size and the round-trip time (the so-called "SSH-2 handbrake"). PuTTY is one such naive implementation (it uses a fixed channel window size of 16k).

The full generality of this problem is addressed in flow-control. A simple approach is possible where a connection only has (and only ever will have) one channel running over it, since in that case PuTTY can open the window fully and leave flow control to TCP.

As something of an aside, it might also be helpful for PuTTY to indicate somehow to the server that it only plans to use a single channel on a connection so that the server can open its window fully too. Otherwise, we only get improved download performance.

PSCP and PSFTP do both of these as of r7679, and get decent download performance. (We're not aware that any server yet takes any notice of our simple@putty.projects.tartarus.org hint, though.)


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2017-04-28 16:52:45 +0100)