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
