> - Log -----------------------------------------------------------------
> commit 7899d28ecbb3f2c0330429ea9c47834167fe2f7f
> Author: Daniel Stenberg <daniel_at_haxx.se>
> Commit: Daniel Stenberg <daniel_at_haxx.se>
> sftp_write: handle "left over" acked data
> The SFTP handle struct now buffers number of acked bytes that haven't
> yet been returned. The way this is used is as following:
> 1. sftp_write() gets called with a buffer of let say size 32000. We
> split 32000 into 8 smaller packets and send them off one by one. One of
> them gets acked before the function returns so 4000 is returned.
> 2. sftp_write() gets called again a short while after the previous one,
> now with a much smaller size passed in to the function. Lets say 8000.
> In the mean-time, all of the remaining packets from the previous call
> have been acked (7*4000 = 28000). This function then returns 8000 as all
> data passed in are already sent and it can't return any more than what
> it got passed in. But we have 28000 bytes acked. We now store the
> remaining 20000 in the handle->u.file.acked struct field to add up in
> the next call.
> 3. sftp_write() gets called again, and now there's a backlogged 20000
> bytes to return as fine and that will get skipped from the beginning
> of the buffer that is passed in.
What a mess. :\ Not so much the implementation but the problem..
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.
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.
Received on 2010-11-11