D29634: sftp: break large writes into multiple requests

[Harald Sitter]

sitter added inline comments.

INLINE COMMENTS

> meven wrote in kio_sftp.cpp:58
> Why not change it now to 32 * 1024 then ?
> I guess you tested this value works at least  with openssh.
> 
> I guess the best solution would be to ask/figure out the server buffer size.
> 
> What does gvfs, or other libs ?

The reason I am not changing it is because it is out of scope for the bug fix and requires research. I'm also kinda leaning towards keeping it until there's a bug report for a server that doesn't support it. The way the RFC is written reads incredibly open ended to the point where there may be no maximum or it may be even smaller than 32kb.

> feverfew wrote in kio_sftp.cpp:1831-1832
> I'm not sure if that would help. `MAX_XFER_BUF_SIZE` would be the upper bound of this approach, and if the server buffer size is less I imagine we'll crash anyway (as detailed in the bug report). If we simply write less then yes, we can use this to "calibrate" but seeming as it crashes instead then unfortunately I don't think this will work.

What Alex said.

I guess we could try to infer if a write failed because of buffer size but it seems a waste of time in the grand scheme of things (and also has lots of pits to fall into since we'd have to hook onto a callback and then carry out a mid-flight session reset).

In the long run we aren't loosing much by going with a static size and request queuing like we do for read() already. From what I have seen in the past the small requests of sftp become largely irrelevant with queuing and efficient (threaded) encryption.

REPOSITORY
  R320 KIO Extras

REVISION DETAIL
  https://phabricator.kde.org/D29634

To: sitter, ngraham, meven
Cc: meven, feverfew, kde-frameworks-devel, kfm-devel, waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, cblack, fbampaloukas, alexde, Codezela, michaelh, spoorun, navarromorales, firef, ngraham, andrebarros, bruns, emmanuelp, rdieter, mikesomov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20200512/74ece1c2/attachment.htm>