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
