RE: LIBSSH2_SFTP_PACKET_MAXLEN

Hi,

>> I think this is a limitation in the sftp spec itself - it does not mandate a
>> maximum packet size
>
>Yes it does, as we've already quoted and discussed in this thread.

If you are referring to the section I quoted when I started this thread (Section 4 - General Packet Format) - that only states that a server SHOULD accept at least 34000 bytes. It says nothing about the minimum a client should accept or the maximum a server can send.

http://tools.ietf.org/html/draft-ietf-secsh-filexfer-13#page-5

It also says:

      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)

This is true for normal reads and writes because the client specifies how many bytes are being written and read. Not true for directory reads where it is completely up to the server.

Also in this thread Henrik mentioned that there is maximum packet size negotiation at the channel level - that is correct but there is nothing to say that an SFTP layer packet needs to fit in a channel packet (and they don't - in my tests I can see multiple transport and connection packets being combined to make single SFTP packets).

So I stand by my original statement. Having said that I am sure I don't know as much about sftp as you guys so I'm ready to stand corrected.
 
>> Can anyone think of a reason to keep LIBSSH2_SFTP_PACKET_MAXLEN defined in a
>> public header file btw?

It's probably handy to know the maximum packet length since it affects the efficiency of reads and writes (or so the API docs say).

Regards // Mike

_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2011-11-19