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 kind of internal backup queue for cases like these, right? 2018-05-19 11:02 GMT+02:00 Alex H <alexhult...@gmail.com>: > 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@openssl.org> skrev: > >> 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 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 >> >
-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
