D29634: sftp: break large writes into multiple requests

[Méven Car]

meven requested changes to this revision.
meven added inline comments.
This revision now requires changes to proceed.

INLINE COMMENTS

> kio_sftp.cpp:58
>  // you will overflow the 2 byte size variable in a sftp packet.
> +// FIXME: this seems too large
> +// from the RFC:
> +//   The maximum size of a packet is in practise determined by the client
> +//   (the maximum size of read or write requests that it sends, plus a few
> +//   bytes of packet overhead).  All servers SHOULD support packets of at
> +//   least 34000 bytes (where the packet size refers to the full length,
> +//   including the header above).  This should allow for reads and writes of
> +//   at most 32768 bytes.
> +// In practise that means we can assume that the server supports 32kb,
> +// it may be more or it could be less. Since there's not really a system in place to
> +// figure out the maximum (and at least openssh arbitrarily resets the entire
> +// session if it finds a packet that is too large
> +// [https://bugs.kde.org/show_bug.cgi?id=404890]) we ought to be more conservative!
>  #define MAX_XFER_BUF_SIZE (60 * 1024)
>  

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 ?

> kio_sftp.cpp:1831
> +            while (offset < buffer.size()) {
> +                const auto length = qMin<int>(MAX_XFER_BUF_SIZE, buffer.size());
> +                ssize_t bytesWritten = sftp_write(file, buffer.data() + offset, length);

`const auto length = qMin<int>(MAX_XFER_BUF_SIZE, buffer.size() - offset);`

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/b406a6ba/attachment.htm>