> From: openssl-users [mailto:openssl-users-boun...@openssl.org] On Behalf Of
> Alex H
> Sent: Saturday, May 19, 2018 15:53
> To: openssl-users@openssl.org
> Subject: Re: [openssl-users] Receive throttling on SSL sockets
> > Flow control really, really, *really* seems like
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
y, 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
> could have a window, like TCP, where the receiv
> 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 s
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
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
> 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 me
: Rich Salz <rs...@akamai.com>, openssl-users <openssl-users@openssl.org>
Subject: Re: [openssl-users] Receive throttling on SSL sockets
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 TC
mail.com>
>> *Reply-To: *openssl-users <openssl-users@openssl.org>
>> *Date: *Friday, May 18, 2018 at 7:21 PM
>> *To: *openssl-users <openssl-users@openssl.org>
>> *Subject: *[openssl-users] Receive throttling on SSL sockets
>>
>>
>>
>> How do
one side.
>
>
>
> *From: *Alex H <alexhult...@gmail.com>
> *Reply-To: *openssl-users <openssl-users@openssl.org>
> *Date: *Friday, May 18, 2018 at 7:21 PM
> *To: *openssl-users <openssl-users@openssl.org>
> *Subject: *[openssl-users] Receive throttling on SSL so
TLS is a bidirectional protocol. You can’t throttle only one side.
From: Alex H <alexhult...@gmail.com>
Reply-To: openssl-users <openssl-users@openssl.org>
Date: Friday, May 18, 2018 at 7:21 PM
To: openssl-users <openssl-users@openssl.org>
Subject: [openssl-users] Receive
How do you properly implement receive throttling on SSL sockets without
hindering writing?
As opposed to raw TCP sockets, an SSL socket cannot be receive-throttled
simply by stop polling for readable events on the underlying raw TCP
socket. SSL_write still could require reading of data so simply
12 matches
Mail list logo
