> OK, but from the source, I discovered that SSL_read is blocking until it > receives a complete record. So, if I want to be awaken with select I > must either:
Combining 'select' with blocking operations almost never works right. This is the most difficult conceivable situation and you should not willingly choose it. If you are using 'select', use non-blocking operations. If you want to block until operations are possible, don't use 'select', just try the operation. It sounds like you want non-blocking operations. Just remember, with SSL, the order is reversed from TCP. With TCP: Call 'select' to see if the operation is possible. if so, do it. With SSL: Try the operation. If we get a WANT_READ/WANT_WRITE, call 'select'. SSL_pending does not do what you think it does. You simply want to call SSL_read when you want to read and SSL_write when you want to write. If those operations fail, they will tell you to use 'select'. Just remember, if any SSL operation may have made any forward progress, you must try all operations. So if 'SSL_write' tells you 'WANT_READ' and you call 'SSL_read', no matter what it returns (other than a fatal error), the 'WANT_READ' indication is now obsolete and cannot be relied upon. This is the nightmare scenario: You are in an application protocol state where either side can legally send data. But as it happens, we are the ones who are going to send data next. The other side could legally send us data but has no intention of doing so. We need to send data to the other side to make progress. 1) You call SSL_write to send the critical data. But a negotiation is not complete, so it returns 'WANT_READ'. You make a note to 'select' before writing. 2) You call SSL_read just in case the other side sent anything. It reads the negotiation data but no application data. It returns 'WANT_READ'. 3) You now call 'select' to wait before *writing*, and wait for the negotitation data to arrive even though it already has. At this point, we have deadlocked. We are in 'select' waiting for data to arrive to complete the negotiation, but it already has. The application programmer has forgotten that when 'SSL_read' returned 'WANT_READ' that obsoleted the 'WANT_READ' indication from 'SSL_write'. An SSL connection has one application state. At step 3, the state is "need to read some data from the socket in order to give application data". It is an error to 'select' before calling 'SSL_write' in that state. Keep your head screwed on straight with this stuff. ;) DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
