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@xxxxxxxxxxxxxxxxxxxx>:
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
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
