On Thu, 11 Nov 2010, Peter Stuge wrote:
>> The SFTP handle struct now buffers number of acked bytes that haven't
>> yet been returned. The way this is used is as following:
>
> What a mess. :\ Not so much the implementation but the problem..
Yes, it is an unfortunate side-effect of our API and the new multi-packet
approach of doing SFTP.
> It would be nice to change at least _sftp_write() so that it can return more
> bytes as sent than were given to it at this call, but never more than has
> been given to it total.
>
> This would mean a change from the API as it is today, but I think it's the
> only way to make sense of the mess.
That's not a bad idea. There are two drawbacks with it though as I see it: 1)
it is not how read() etc works and we mimic their return code systems a bit in
other aspects so it might be a bit unexpected to users and 2) it is a bit hard
to document and explain in a concise manner.
> If I start by _sftp_write()ing 32000 byte, 4000 get sent, and I then
> continue _sftp_write()ing less-than-28000 byte on every call, there is a
> problem.
It's really not that big of a problem. It is mostly a problem to keep things
correct in the code and in your head when thinking about it! :-)
If you first call it with 32000 bytes and 4000 get sent, and you then switch
to call _sftp_write with 4000 from then on, it will take (at best) 7 of those
calls to get the backlogged ACKs returned back (and in these calls libssh2
can't send off any new packets since no new data is provided yet), but by then
it has adapted and will work "normally" again as it has then dealt with the
backlog.
Luckily, I don't think this kind of situation is very likely to happen much.
-- / daniel.haxx.se _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-develReceived on 2010-11-11