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
