Determine that there is no forward progress with non blocking SSL socket

[Michael Wojcik]

> From: Eran Borovik [mailto:eran.borovik at gmail.com]
> Sent: Wednesday, January 29, 2020 07:32

Please respond to the list rather than directly to me, since the subject
may be of interest to other readers. I'm including the list in this
response.

> The only thing that still confuses me is that if I am reading the docs
> correctly,  SSL_read may return SSL_WANT_WRITE and SSL_write may return
> SSL_WANT_READ even when they don't encounter a blocking condition, but
> because of negotiation.

Right.

> Now, I use edge triggered polling with Epoll (EPOLLET), which means
> that if SSL_read/write decides to give me an WANT* status when the
> socket doesn't have a blocking condition, then epoll will never wake
> and I am stuck (unless I understand that this is the case and retry
> immediately). Is there a way to actually understand that there is a
> blocking condition in the socket from OpenSSL or do I need to use
> select with zero timeout to realize what is the correct condition of
> the socket after each time SSL gives me SSL_WANT*?

Yes, I think you need to test for readability / writability at some
point. You can do that immediately when you get a WANT_*, or you can
have your epoll time out periodically and test then if you have
pending I/O.

Personally, I'm leery of edge-triggered activation for this reason.
It's too easy to miss some race condition or other case where you
might end up blocked forever. I'd always have epoll time out so you
can do a level-poll of all sockets that have pending operations;
that turns a failure mode into one that simply has suboptimal
performance, at a small resource cost.

--
Michael Wojcik
Distinguished Engineer, Micro Focus