Subject: Re: SFTP slow read in libssh2 compared to SecureCRT

Re: SFTP slow read in libssh2 compared to SecureCRT

From: Lars Nordin <>
Date: Thu, 26 Mar 2015 00:19:36 +0100

On 2015-03-25 23:53, Daniel Stenberg wrote:
> On Wed, 25 Mar 2015, Lars Nordin wrote:
>> and I get 2000 bytes each time. The testfile is 116K.
> Let me explain in rough terms why you see this 2000 bytes data and how
> the libssh2 SFTP code works.
> The SFTP code will take your given buffer size and split it into 2000
> bytes chunks and ask the server for such data packets, as many as can
> fit in your buffer.
> A 20000 buffer thus ends up asking for 10 such packets - at once.
> libssh2 will then return data back as soon as there is data to return,
> which initially could be a single 2000 bytes packet but over time
> should become a whole bunch of such packets assuming the bandwidth is
> good enough.
But the code is just returning one packet of data, ie 2000 bytes (as I
get all the time)
rc32 = _libssh2_ntohu32(data + 5);
if(rc32 > 0) {
                     /* we must return as we wrote some data to the
buffer */
                     return rc32;

the buffer is just one chunk, from your explanation I thought I would
find something like:
outlen +=rc32

and a buffer-pointer slider through the receive-buffer in the
sftp_read() parameter.
> This concept is used because SFTP requires ACKs for ever packet it
> asks for so it better ask for a whole bunch at once to suffer less RTT
> pains.
My WireShark session tells different, I see a client package, and the 1
to 4 server packages, the output should be 10 client packages asking for
data (or maybe only one??) and then 10 server packages (using your example)

I will try to read the code and add some debug.

My 76M file transfers in 44 minutes using SFTP_read, 81s using SecureCRT
SFTP_read and 12s using scp...


Received on 2015-03-26