>> > The most critical part is file transfer.
>>
>> You're then referring to SFTP here. But AFAIK, libssh2 is
>> also slower on pure
>> SCP transfers... Isn't it? Did anyone actually measure
>> libssh2 transfers
>> recently and compared them to the openssh tools?
You are right, it affects scp also. When we started using libssh2 in our
product we received complaints about the performance. We did some tests
with libssh2-0.12 (with our own patch to change the 16 byte read loop
into 32kb read loop) and we came to a conclusion that libssh2 is roughly
50% slower in file transfer than the command line counterparts. Eg. we
had one test run where we transferred a 100MB file, command line scp
took 58 seconds and libssh2 a bit over 2 minutes.
>> > Consider that you are transferring a 2MB file, you send
>> I wouldn't call it asynchronous, I would all it pipelining
>> (since the data
>> would still be synchronously sent) but then I might just be
>> http damaged! ;-)
Terminology scherminology ;-) but pipelining is a better term for it.
>> I disagree with that conclusion. First, there's of course
>> nothing that prevents us from adding another or a modified
>> API that somehow makes this easier, but I could very well
>> consider just an added function/option to the library that
>> would make libssh2 ask for several chunks of data at once
>> and just build an internal buffer to return to the API when
>> asked for (of course limited to a certain extent beyond
>> what has been asked for). The option would be needed
>> because it would of course risk asking for and transferring
>> more data than what the application would otherwise want.
>> And when sending data to a peer, the function could accept
>> a large chunk of data split it up and send it off in many
>> pieces more or less at once without necessarily waiting for
>> each packet to first receive success. That will of course
>> require that apps send very large data chunks to the
>> libssh2 API, but should be a matter of documentation.
libssh2_sftp_read_many(LIBSSH2_SFTP_HANDLE *handle,
char *buffer,
size_t buffer_maxlen,
ulong upto)
Where 'upto' would specify the expected size of the target of the read
operation, for example the file size. Appropriate timeouts would be
applied, just a bit longer than for a normal read opreation. If upto is
zero, function would fall back to libssh2_sftp_read().
Would that make any sense?
>> Of course this kind of pipelining approach will make error
>> handling somewhat tricker.
well, it might block a bit longer, but basicly the requests either
succeed or fail. The function could remove all the received data and
return an error or it could always return the amount successfully
received sequential data and the application should check whether it
matches the expected amount of data (eg. upto).
>> Personally I would prefer to start with improving SCP as
>> that's a much simpler
>> protocol and if that is still slower than openssh I think we
>> should focus on
>> getting that up to speed first and then attack SFTP.
But SCP is not compatible with all SSH implementations. We are using
libssh2 in mixed environments and sometimes OpenSSH jsuts isn't an
option.
br,
/jUSSi
--
perl -e '[EMAIL PROTECTED],0112,0,0],[0,0101,0,0],
[0,0120,0,0],[0,0110,0,0]];$[=256/8-0x1D;
print(chr(@{$_}[+($[+1-1+1)]))for(@[EMAIL PROTECTED]);'
____________________________________________________________________________________
Comptel Finland is moving to new premises.
Starting from July 9 our new visiting address is Salmisaarenaukio 1, 00180
Helsinki,
and the postal address is P.O.Box 1000, FI-00181 Helsinki
____________________________________________________________________________________
Disclaimer: This message and any attachments thereto are intended solely for
the addressed recipient(s) and may contain confidential information. If you
are not the intended recipient, please notify the sender by reply e-mail and
delete the e-mail (including any attachments thereto) without producing,
distributing or retaining any copies thereof. Any review, dissemination or
other use of, or taking of any action in reliance upon, this information by
persons or entities other than the intended recipient(s) is prohibited.
Thank you.
-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
libssh2-devel mailing list
libssh2-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
