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

[Eran Borovik]

Hi all,
My application is using non-blocking sockets to send and receive data. To
avoid issues, my code guarantees that a specific socket is always owned by
a specific thread, thus preventing any issues or races from concurrently
running send and receive at the same time on the same socket.
I've read thoroughly the lists regarding the best way to use non blocking
sockets with SSL. The common wisdom I gathered was:
-It is allowed to interleave SSL_read and SSL_write, meaning that SSL_read
doesn't have to complete successfully before issuing SSL_write( this makes
sense otherwise full-duplex doesn't work).
-SSL socket has a global state. So return value from one call negates a
previous return value from other call.

My question is how to determine that forward progress isn't possible and to
return to epoll.
Suppose I have a main-loop that deals with all the pending receives and
sends for a specific socket. For simplicity, assume that I try to
SSL_receive until I get some kind of an error (WANT_READ or WANT_WRITE).
Then I try to issue SSL_send until I get error as well, but if I read
correctly the group, the new error negates previous errors so prior
receives must be retried.
When do I stop? what is the best way to actually determine there can be no
more forward progress both on the send and the receive side, and epoll must
be used?

I can think on the following "algorithm" but  I am not sure if it makes
sense:
-Receive until you get an Error X.
-Send. If I receive a return value that isn't X, it means receive will have
to be retried. If I immediately receive a return value that is X, it means
that no more progress is possible and I need to wait with epoll.

Problem with the above algorithm, is that I am afraid that if the send
buffer is full and there is nothing to receive, I will keep getting
WANT_READ for receive, and WANT_WRITE for send until actual data arrives or
can be sent which defeats the purpose of epoll.

I've been banging my head here for several days. Any help here will be much
appreciated.

Thx,
Eran
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20200127/c105e845/attachment.html>