[openssl-users] Receive throttling on SSL sockets

[Alex H]

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 solution (I guess?) would be to stop polling for readable until
SSL_write demands data then immediately stop polling for readable again
once SSL_write is happy. In the case of getting unwanted data while
throttling then SSL_peek can be used instead of SSL_read. That would not
guarantee no buildup but would work for the most part, right?

Do you see any flaw with this? Could it still fail due to mass buildup when
throttling for long?

Den lör 19 maj 2018 04:57Salz, Rich via openssl-users <
openssl-users at openssl.org> skrev:

> TLS is a bidirectional protocol.  You can’t throttle only one side.
>
>
>
> *From: *Alex H <alexhultman at gmail.com>
> *Reply-To: *openssl-users <openssl-users at openssl.org>
> *Date: *Friday, May 18, 2018 at 7:21 PM
> *To: *openssl-users <openssl-users at openssl.org>
> *Subject: *[openssl-users] Receive throttling on SSL sockets
>
>
>
> 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 stop
> polling for readable would potentially hinder writing of data which is not
> okay.
>
>
>
> Is there any such receive-throttling functionality in the SSL protocol
> itself? I don't see how SSL_peek would solve the issue since I would still
> be buffering (potentially uncontrolled amount of) data in a BIO.
>
>
>
> Even if I would _only_ enable readable polling when _absolutely needed_ as
> per SSL_write error, I still cannot guarantee not reading a chunk of data
> (which I would then need to buffer up in a BIO since the application is not
> expecting it).
>
>
>
> How are we supposed to solve this issue without potentially building up
> backpressure?
>
>
>
> Thanks
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20180519/a61ca8be/attachment.html>