<div>After looking through the SSH code and learning more about it, I feel this patch is solving the wrong problem.  The REAL problem is that ssh_connection:send() is supposed to be synchronous, but is actually not in some cases.</div>
<div><br></div><div>send() will be synchronous only if the given data will fit in the channel send window.  Any data beyond that will be sent asynchronously.  So if you send a very large binary, or repeatedly send smaller binaries you will run into this problem.</div>
<div><br></div><div>The minimum ssh packet size mandated by the RFCs is 32kB, so the minimum window is the same.  OpenSSH gives me a send window of approx 200kB.  For most of the applications that people use SSH for, the send window never gets overrun and you never see asynchronous send behavior out of Erlang SSH.</div>
<div><br></div><div>Ingela, I'm inclined to write some failing test cases for this and some other problems I've seen.  Would this be helpful? I have some ideas about how to fix the problems, but I may not have time to actually fix them.</div>
<div><br></div><div>Dan.</div><div><br></div><br><div class="gmail_quote">On Tue, Aug 28, 2012 at 3:31 PM, Daniel Goertzen <span dir="ltr"><<a href="mailto:daniel.goertzen@gmail.com" target="_blank">daniel.goertzen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">When sending a large binary (say a couple of MB) followed by an eof through an ssh channel using the following...</span><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">

<br></div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif"><br></div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">
ssh_connection:send(Conn, Chan, BigBinary),</div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">ssh_connection:send_eof(Conn, Chan),</div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">

<br></div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">... the eof is transmitted asynchronously and any untransmitted portion of BigBinary will be lost.</div>
<div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif"><br></div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">
<br></div></div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">The patch linked below puts eofs through the existing data-send path so that all queued send data will be sent before the eof.</div>

<div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif"><br></div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">
The data-send pathway previously only carried {DataType, Data} tuples; it may now also carry 'eof' atoms.  To abstractly represent both in the code I use the name "Cmd" (Command).</div><div style="color:rgb(34,34,34);font-size:13.333333969116211px;font-family:arial,sans-serif">

<br></div><div><br></div><div>Tested on Windows.</div><div><br></div><div><br></div>git fetch git@github.com:goertzenator/otp.git ssh_sync_eof<div><br><div><a href="https://github.com/goertzenator/otp/compare/ssh_sync_eof" target="_blank">https://github.com/goertzenator/otp/compare/ssh_sync_eof</a></div>

<div><br></div><div><a href="https://github.com/goertzenator/otp/compare/ssh_sync_eof.patch" target="_blank">https://github.com/goertzenator/otp/compare/ssh_sync_eof.patch</a> </div><div><br><div><br></div></div></div><div>
Dan.</div>
</blockquote></div><br>