Jacob Nevins <jacobn+secsh%chiark.greenend.org.uk@localhost> writes:
How about the following change to secsh-connect 5.1, which makes the
'maximum packet size' language match that used for 'initial window
size'?:
The 'maximum packet size' specifies the
maximum number of bytes of channel data that may be sent to the
sender in a single SSH packet.
It's not entirely trivial to make this clear. I would propose a change
to section "5.2 Data transfer", in the description of
SSH_MSG_CHANNEL_DATA.
Before:
The maximum amount of data allowed is the current window size. The
window size is decremented by the amount of data sent. Both parties
MAY ignore all extra data sent after the allowed window is empty.
After:
The maximum amount of data allowed is determined by the maximum
packet size for the channel, and the current window size, whichever
is smaller. The window size is decremented by the amount of data
sent. Both parties MAY ignore all extra data sent after the allowed
window is empty.
*Maybe* also add a clarification along these lines:
Implementations are expected to have some limit on the ssh
transport layer packet size (any limit for rececived packets MUST
be 32768 bytes or larger, as described in [SSH-TRANSPORT]). The
implementation of the SSH connection layer
* MUST NOT advertise a maximum packet size that would result in
transport packets larger than its transport layer is willing to
receive.
* MUST NOT generate data packets larger that its transport layer is
willing to send, even if the remote end would be willing to
accept very large packets.
Although I feel this text is much too long, and we probably shouldn't
say anything about this at all if we can't say it more concisely. The
first point is a clarification of the actual wire protocol, it says
that if the other end advertises a huge maximum packet size, it can
also be expected to accept huge packets, and in this case it is safe
to send packets larger than 32768 bytes. The second point is almost
self-evident; if your transport layer can't send a 10 MB packet, don't
do that, and don't rely in the *remote* end to advertize a maximum
packet size that is supported by your implementation.
Regards,
/Niels