Resend; it's been a few hours and my reply below has yet to come through. - Andrew
-----Original Message----- From: Andrew Armstrong [mailto:[EMAIL PROTECTED] Sent: Thursday, 17 May 2007 6:49 PM To: 'openssl-users@openssl.org' Subject: RE: Multi-threaded SSL Socket Usage Thanks for your response David, Rodney. I understand (clearer now) the requirement that: * If SSL_read reports WANT_WRITE; we need to issue an immediate SSL_write However; what do I actually write? Do I write a blank/empty string (SSL_write(ssl, "", 0)?) - I may not have anything to write. Please confirm? * If SSL_read reports WANT_READ; re-try the read, before issuing an SSL_write before the retry of the read. Please confirm? * If SSL_write reports WANT_WRITE; re-try the write immediately, without issuing an SSL_read before the retry of the write. Please confirm? * If SSL_write reports WANT_READ; issue an SSL_read on the socket before issuing an SSL_write. Once the READ has been done, re-do the SSL_write. Please confirm? Additionally; the logic to selecting sockets for reading should be: * If the readfd of the socket is set (via select()) OR * The socket has reported WANT_READ from an operation Can you please provide your thoughts on the above logic? Many thanks for the help so far. Regards, Andrew -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Schwartz Sent: Wednesday, 16 May 2007 3:19 AM To: openssl-users@openssl.org Subject: RE: Multi-threaded SSL Socket Usage > 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] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
