Rij: > > If you get SSL_ERROR_WANT_READ, you need to epoll/select for ? > readability. If > > you get SSL_ERROR_WANT_WRITE, you need to epoll/select for readability.
> I am assuming the above was a typo and you meant writeability for > SSL_ERROR_WRITE. Correct. > Ok. That's interesting. I actually followed the concept from non > blocking tcp connect where you monitor the socket for both readability > and writeability. So accordingly I had set epoll to: EPOLLIN | > EPOLLOUT. Never, ever monitor any SSL socket for anything unless specifically told to do so by OpenSSL. Do not *ever* assume that reading from the underlying socket means reading decrypted data or that writing decrypted data will mean writing to the socket. Do not second-guess the state machine. That will lead to all kinds of pain. > Now making the above change definitely helped. So now, the while loop > is executing once most of the time. But every once in a while (I > connect to 100 servers every 1 second), the value goes up to close to > 100. Any particular reason for that? I'd have to see your code to make sure it's correct. Do not *ever* refuse to make forward progress on a socket until you get a select/epoll hit unless OpenSSL specifically told you to wait for that direction on that socket. The usual problem with getting this wrong would be deadlock. However, since you're having the opposite problem, my bet is that you are testing for forward progress on the wrong connection when you do get a select/epoll hit. (That will hurt performance, but won't lead to incorrect operation.) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
