<table><tr><td style="">sitter added inline comments.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D29634">View Revision</a></tr></table><br /><div><strong>INLINE COMMENTS</strong><div><div style="margin: 6px 0 12px 0;"><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D29634#inline-169806">View Inline</a><span style="color: #4b4d51; font-weight: bold;">meven</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kio_sftp.cpp:58</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">Why not change it now to 32 * 1024 then ?<br />
I guess you tested this value works at least  with openssh.</p>

<p style="padding: 0; margin: 8px;">I guess the best solution would be to ask/figure out the server buffer size.</p>

<p style="padding: 0; margin: 8px;">What does gvfs, or other libs ?</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">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.</p></div></div><br /><div style="border: 1px solid #C7CCD9; border-radius: 3px;"><div style="padding: 0; background: #F7F7F7; border-color: #e3e4e8; border-style: solid; border-width: 0 0 1px 0; margin: 0;"><div style="color: #74777d; background: #eff2f4; padding: 6px 8px; overflow: hidden;"><a style="float: right; text-decoration: none;" href="https://phabricator.kde.org/D29634#inline-169827">View Inline</a><span style="color: #4b4d51; font-weight: bold;">feverfew</span> wrote in <span style="color: #4b4d51; font-weight: bold;">kio_sftp.cpp:1831-1832</span></div>
<div style="margin: 8px 0; padding: 0 12px; color: #74777D;"><p style="padding: 0; margin: 8px;">I'm not sure if that would help. <tt style="background: #ebebeb; font-size: 13px;">MAX_XFER_BUF_SIZE</tt> 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.</p></div></div>
<div style="margin: 8px 0; padding: 0 12px;"><p style="padding: 0; margin: 8px;">What Alex said.</p>

<p style="padding: 0; margin: 8px;">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).</p>

<p style="padding: 0; margin: 8px;">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.</p></div></div></div></div></div><br /><div><strong>REPOSITORY</strong><div><div>R320 KIO Extras</div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D29634">https://phabricator.kde.org/D29634</a></div></div><br /><div><strong>To: </strong>sitter, ngraham, meven<br /><strong>Cc: </strong>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<br /></div>