<div dir="ltr">Yeah TCP is really the same as TLS in terms of being "bidirectional". Even if you stop polling for readable and never call recv, you will still receive ACKS for whatever you write.<div><br></div><div>A receive window for TLS implemented completely ontop of TCP would solve this issue and allow applications to truly throttle data receives without hindering their own writes or forcing them to buffer up data.</div></div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-19 20:07 GMT+02:00 Jordan Brown <span dir="ltr"><<a href="mailto:openssl@jordan.maileater.net" target="_blank">openssl@jordan.maileater.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF"><span class="">
    <div class="m_5985907641652894585moz-cite-prefix">On 5/19/2018 6:51 AM, Michael Wojcik
      wrote:<br>
    </div>
    <blockquote type="cite">Right.
      And TCP is an ordered byte-stream protocol. That means to receive
      a control message from the peer, the local stack *must* have
      received everything transmitted prior to it. (Modulo SACK, but
      SACK'd data preceeded by a gap is invisible to the application, so
      we should ignore it.)</blockquote>
    <br></span>
    And yet TCP itself moves ACKs when there's no window available.<br>
    <br>
    TLS could (but as far as I can tell does not) have such a
    mechanism.  It could have a window, like TCP, where the receiver
    would say "you can send me 64K of data", and the sender wouldn't be
    allowed to send data (but could send control messages) when that
    window is exhausted, until the receiver reopens the window.  It
    could have control messages like XON and XOFF that say "please stop
    sending me data (but control is OK)" and "resume sending data".<br>
    <p>Each scheme has its problems (mostly around how much data can be
      in flight at any one time), but they're both clearly possible.</p>
    <p>It does seem like some sort of flow control would be desirable,
      so that the receiver doesn't have to have some way to handle
      arbitrarily large amounts of data to keep the connection healthy.</p>
    <p>Maybe in TLS 1.4.<span class="HOEnZb"><font color="#888888"><br>
    </font></span></p><span class="HOEnZb"><font color="#888888">
    <pre class="m_5985907641652894585moz-signature" cols="72">-- 
Jordan Brown, Oracle Solaris</pre>
  </font></span></div>

</blockquote></div><br></div>