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

[Eran Borovik]

Hi,
Excellent, so I think I am finally understanding this correctly. And yes,
we do have epoll timeouts to clean up all sort of missed race conditions
and bugs (either in kernel or user mode).
For performance reasons, EDGE trigger is a must for my application.
What if instead of using select to understand the socket status (big
hammer), I will simple retry the call?
For example, if SSL_read returns WANT_*, I do another SSL_read. On the low
chance that this is a negotiation, there will be forward progress and I am
fine. If not, I know that the socket is blocked.
It is too bad that I cannot differentiate between the two states without
going to kernel space. I wish there were some way by just querying SSL. I
see that there is a family of SSL_want* methods. Can these be of use?

Regards,
Eran.

On Wed, Jan 29, 2020 at 6:12 PM Michael Wojcik <
Michael.Wojcik at microfocus.com> wrote:

> > 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200129/24deae8a/attachment.html>