I should make it clear that I don't have a stake here. Lack of flow
control hasn't caused me problems personally, and I'm not responsible
for implementing and maintaining a TLS infrastructure. This is purely
an intellectual exercise for me.
There were comments suggesting that, because TLS is an
> Flow control really, really, *really* seems like an application-layer
task to me in the case of TLS. I think adding it to TLS itself would be a
mistake.
This whole thread of messages kind of already concluded that this is not
possible currently. You simply cannot implement proper flow control s
> From: Jordan Brown [mailto:open...@jordan.maileater.net]
> Sent: Saturday, May 19, 2018 14:08
> To: openssl-users@openssl.org; Michael Wojcik; Alex H
> Subject: Re: [openssl-users] Receive throttling on SSL sockets
> TLS could (but as far as I can tell does not) have such a mechanism. It
> cou
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 t
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
> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Salz, Rich via openssl-users
> Sent: Saturday, May 19, 2018 08:48
> To: Alex H; openssl-users@openssl.org
> Subject: Re: [openssl-users] Receive throttling on SSL sockets
> There are TLS control messages which could f
There are TLS control messages which could flow in either direction,
spontaneously. Renegotiation (pre TLS 1.3), tickets (TLS 1.3), and so on.
I cannot comment on if your proposal would work or not, sorry.
From: Alex H
Date: Saturday, May 19, 2018 at 5:03 AM
To: Rich Salz , openssl-users
Subj
I think the best solution would be to simply state in the documentation of
my implementation that "throttling receives on SSL sockets will
significantly reduce data receive but will not guarantee a total halt".
Agree?
What do you think of the way Node.js handles this? They _must_ be using
some ki
Okay that's a good theoretical answer but practically not very useful.
I know for instance Node.js to implement their Streams interface with both
TCP and SSL sockets. They both have pause / resume functions for
receive-throttling and I've tested it with SSL and it seems to work somehow.
One solut
