Old thread, sorry I didn't get this sent out sooner.
Daniel Stenberg wrote:
>>> I've now limited libssh2 to only take 32500 bytes payload when it
>>> creates an FXP_WRITE packet.
>>
>> Out of curiosity, where does this 32,500 byte limit come from? Is
>> it a protocol limit?
>
> It was a bit taken out of the air
The number came from me. I suggested to try it as buffer size to get
as large packets at possible yet avoid another libssh2 bug, once the
problems with >1024 had been fixed.
> the draft we're following[*] says:
>
> All servers SHOULD support packets of at least 34000 bytes (where the
> packet size refers to the full length, including the header above).
> This should allow for reads and writes of at most 32768 bytes.
>
> [*] = http://tools.ietf.org/wg/secsh/draft-ietf-secsh-filexfer/draft-ietf-secsh-filexfer-02.txt
That's SFTP, but the bug I'm talking about is in the transport layer
and not SFTP specific.
The length field that the abouve quote refers to is defined as:
uint32 length
So the protocol limit is 2^32. filexfer draft 13 (yes, later than 02)
reads as follows, immediately before your quote:
The maximum size of a packet is in practice determined by the
client (the maximum size of read or write requests that it sends,
plus a few bytes of packet overhead).
I think it's important for SFTP to support large packets but I think
the transport layer is even more fundamental, and whatever solution
is found for that will allow SFTP to follow suite.
Daniel Stenberg wrote:
>> I think they do, in the sense that if an app gives libssh2 a 64kb buffer
>> then I think that should be the payload of a single SSH packet.
>
> 64K is too large for a single packet
No. What gives you this impression?
>> Yep, and it'll work, but packet size is still stuck at the
>> (32k-overhead) limit in the transport layer, which I think is the
>> real problem.
>
> But the 32-34K something is a real limit imposed by the specs, it's
> not something we have invented.
--8<-- RFC 4253 6. Binary Packet Protocol
Each packet is in the following format:
uint32 packet_length
-->8--
And:
--8<-- RFC 4253 6.1. Maximum Packet Length
All implementations MUST be able to process packets with an
uncompressed payload length of 32768 bytes or less and a total packet
size of 35000 bytes or less (including 'packet_length',
'padding_length', 'payload', 'random padding', and 'mac'). The
maximum of 35000 bytes is an arbitrarily chosen value that is larger
than the uncompressed length noted above. Implementations SHOULD
support longer packets, where they might be needed. For example, if
an implementation wants to send a very large number of certificates,
the larger packets MAY be sent if the identification string indicates
that the other party is able to process them. However,
implementations SHOULD check that the packet length is reasonable in
order for the implementation to avoid denial of service and/or buffer
overflow attacks.
-->8--
//Peter
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2010-08-09