> The design of the application is that there are worker threads which > pick up data and send them out via the sockets. This works for the most > part, however as mentioned it will sometimes no longer appear to work > (data is not received in a timely fashion for example). I would think > this is just do to how complex the read/write logic is for openssl, > nonblocking multi-threaded applications.
The most common non-obvious cause of this problem is failure to retry an operation even though something changed after the last time you tried it. It is important to retry all operations any time you make any forward progress, not just the operation you think you made forward progress on. For example, here's a common way you can deadlock: Assume that your side is supposed to send next and the other side won't send any data until you do. The other side has just sent some negotiation data but you haven't received it yet. You can't send any data until you get it. Now imagine this happens: 1) You call SSL_write, you get a 'WANT_READ' indication because the negotiation data has not arrived yet. 2) The negotiation data arrives on the socket. 3) You call SSL_read and it returns 'WANT_READ' because the negotiation data gave it no application data. It has now read the negotiation data. 4) You select for readability on the socket because both SSL_write and SSL_read failed. You do not call SSL_read or SSL_write again until select tells you to. You are now deadlocked. You will not retry SSL_write until you read some data. But the data you are waiting for has already arrived and been read (in the call to SSL_read). You must think very carefully about what the return values mean and retry all operations (read and write) any time there's any chance that forward progress has been made. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
