www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: Re: libssh2-1.2.8-20110111 issue

Re: libssh2-1.2.8-20110111 issue

From: Daniel Stenberg <daniel_at_haxx.se>
Date: Fri, 21 Jan 2011 09:25:18 +0100 (CET)

On Fri, 21 Jan 2011, zl liu wrote:

> If i change the code in sftp_write_sliding.c like this:
>
> if(memuse - rc) {
> /* make room for more data at the end of the buffer */
> /* the mem has been copied by sftp_write() in the previous call,
> just move the count not really memory*/
> // memmove(&mem[0], &mem[rc], memuse - rc);
> memuse -= rc;
> }
> else
> /* 'mem' was consumed fully */
> memuse = 0;
>
> does it work normally? even like this, i think the memory from 0
> to memuse has been waste.

Great question. It certainly shows you understand the internal logic now! I'll
take this opportunity to answer in a long version to sum up the situation.

My answer:

Yes but no. The ABI for this function is still the same as libssh2 has
provided for years[1], and we do not break it now[2]. Thus, even if we may
guess that the library has copied the data since we have read its current
source code, it returned how much data it had handled and everything apart
from that specific amount MUST be passed back to the library again. You MUST
not rely on any other behavior by the library.

We will keep the right to modify the internal behaviors as long as the ABI is
kept, and I can very well suspect that we may alter these algorithms slightly
in the future when we get more data and more reports from users that try this
out in the real world, and then it might not for example copy all the data
but may have a max value that gets calculated dynamically based on the ongoing
performance - or whatever.

[1] = one can argue that it is a slight deviation in the fact that if you send
a buffer with a length A, libssh2 returns length B, and then modify the buffer
beyond position A before you call libssh2 again and libssh2 will not notice
the change but send the original data anyway. I've made a guess that this kind
of usage is very rare and should not be a concern for the vast majority of
users.

[2] = we work really hard on maintaining a stable API and ABI so that
applications and surroundings keep working even when we improve libssh2. This
is a sometimes ungrateful work involving pain, but it pays out in the long
run. In this particular case with SFTP transfers, we've discussed introducing
new functions that better offer the pipelined transfer we need to get really
good transfer speeds, but nothing has yet happened on that front.

-- 
  / daniel.haxx.se
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2011-01-21

the libssh2 team