> 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
@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 receiver
> > would say "you can send me 64K
> 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
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 me
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 TCP
and SSL sockets. They both have pause / resume functions for receive-throttling
rottling for long?
>
> Den lör 19 maj 2018 04:57Salz, Rich via openssl-users <
> openssl-users@openssl.org> skrev:
>
>> TLS is a bidirectional protocol. You can’t throttle only one side.
>>
>>
>>
>> *From: *Alex H
>> *Reply-To: *openssl-users
&g
ottle only one side.
>
>
>
> *From: *Alex H
> *Reply-To: *openssl-users
> *Date: *Friday, May 18, 2018 at 7:21 PM
> *To: *openssl-users
> *Subject: *[openssl-users] Receive throttling on SSL sockets
>
>
>
> How do you properly implement receive throttling on SSL soc
TLS is a bidirectional protocol. You can’t throttle only one side.
From: Alex H
Reply-To: openssl-users
Date: Friday, May 18, 2018 at 7:21 PM
To: openssl-users
Subject: [openssl-users] Receive throttling on SSL sockets
How do you properly implement receive throttling on SSL sockets without
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 s
12 matches
Mail list logo
