[openssl-users] Receive throttling on SSL sockets

[Alex H]

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.

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.

2018-05-19 20:07 GMT+02:00 Jordan Brown <openssl at jordan.maileater.net>:

> On 5/19/2018 6:51 AM, Michael Wojcik wrote:
>
> 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.)
>
>
> And yet TCP itself moves ACKs when there's no window available.
>
> 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".
>
> Each scheme has its problems (mostly around how much data can be in flight
> at any one time), but they're both clearly possible.
>
> 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.
>
> Maybe in TLS 1.4.
>
> --
> Jordan Brown, Oracle Solaris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/60bdf90a/attachment.html>