Sftp: performance enhancing changes

[Joseph Galbraith <galb%vandyke.com@localhost>]

We had a discussion of sftp performance.  I don't
think we really reached an consensus about a change.

The following things were brought up:

o Ignoring channel window makes for a screaming
  sftp transfer. (unacceptable, breaks multiplexing.)

o I proposed a new SSH_FXP_MULTI_READ that would make
  it easier to do large data transfers.

o An implementation hints section with some verbage
  about issuing multiple simultaneous read and write
  requests to obtain maxmimum performance.

Do we want to do any of these things. (Well, the
first is unacceptable of course.)

Here is the proposed MULTI_READ request:

> However, in order to facilitate writing
> higher performing SFTP clients, I have
> considered that it might make sense to
> add a second read command to SFTP, which
> allowed reads of any size, but which can
> result in multiple data packets, culminating
> in a final status packet.
>
> I.E.
>   Client: SSH_FXP_MULTI_READ: req-id=243, offset=0, bytes=4,000,0000
>   Server: SSH_FXP_DATA: req-id=243, 64K
>   Server: SSH_FXP_DATA: req-id=243, 64K
>   Server: SSH_FXP_DATA: req-id=243, 64K
>   ...
>   Server: SSH_FXP_DATA: req-id=243, 64K
>   Server: SSH_FXP_STATUS: req-id=243, SUCCESS
>
> or
>   Server: SSH_FXP_DATA: req-id=243, 64K
>   Server: SSH_FXP_DATA: req-id=243, 64K
>   Server: SSH_FXP_STATUS: req-id=243, EOF
>
> This would allow a client to request the entire
> file in a single read operation without requiring
> the server to allocate huge buffers or being
> vulnerable to corner cases (such as mid-read
> truncation.)

So, what do we want to do?

Joseph