[Bug 1141] Is there a sound reason for MAX_MSG_LENGTH being 256KB?

[bugzilla-daemon at mindrot.org]

http://bugzilla.mindrot.org/show_bug.cgi?id=1141


djm at mindrot.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




------- Comment #1 from djm at mindrot.org  2006-01-02 12:25 -------
The protocol doesn't have any mechanism to support negotiation of packet sizes
and only requires that clients and servers accept a minimum of 32k. It doesn't
gave any means to report "this message was discarded because it was too big"
either.

256kB is a pretty large packet size for sftp and if the peer is properly
designed (i.e. maintains a window of pending requests, which WinSCP does) then
increasing the packet size doesn't improve performance. For example, increasing
the packet size from 256kB to 512kB would reduce overhead by less than .006%. 

On the other hand, as sftp is a packetised protocol, increasing the packet size
has a negative effect on application responsiveness - e.g. in OpenSSH ^C is
only processed on packet boundaries.

In answer to your last question, if you modify the server to support a larger
maximum size then you will still be able to connect with any client (though I
don't see what the point is) because it is the client that determines the
length of requests and therefore the size of the server's replies. If you
modify the client to use larger messages by default, then you will break when
connecting to servers that don't support the larger messages.

I have made SFTP_MAX_MSG_LENGTH common to both sftp-server and sftp, but given
the above, its actual value is not going to change.




------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.