Re: Why SFTP performance sucks, and how to fix it

[Bill Sommerfeld <sommerfeld%east.sun.com@localhost>]

I believe I may have been responsible for demonstrating to one of the
sshv1 implementors why the omission of per-channel flow control was a
mistake.

I don't recall exactly *which* test case I used to demonstrate it but
it either involved regular connection forwarding or X11 forwarding.

In short, if you pause an entity reading off a channel, you either
need infinite buffering in the ssh receiver point (to allow the
receiver to read and buffer arbitrary amounts of data for the paused
channel), or else you will end up flow-controlling the ssh connection,
possibly leading to a deadlock (because the only way to unpause the
channel is by sending data over another channel..)

example: stopping an X client using either UNIX job control or a
debugger.  the X client will keep receiving events from the X server
while stopped; eventually enough will build up to begin to require
flow control backpressure..

If the main ssh pipe is blocked, you can't send the "continue"..

Now, I think the trick for good performance is to ensure that the ssh
windows are large enough that when the applications are *not* flow
controlled you can keep the the TCP pipe filled more often than not.
I suspect this means "somewhat larger than the TCP window".  But some
experimentation is likely in order..


						- Bill