Henrik Thuermer wrote:
If we receive some data we process it via one BIO_write call followed by SSL_read calls until the call to SSL_read fails with SSL_get_error() == SSL_ERROR_WANT_READ or SSL_read returns no more data (SSL_ERROR_WANT_WRITE is also handled correctly - I hope). Then we stop reading from the ssl connection until we receive new data.
Just to confirm your understanding on this point, as your description is unclear. You may not necessarily receive new data, as in new application level data.
Once you get a WANT_READ from an SSL_write(), you do your call of SSL_read() as necessary to service inbound data.
It is safe to keep trying SSL_write() after every SSL_read() to see if it can do more work, otherwise it will persist with the WANT_READ state.
If you are non-blocking the only special case is to start ignoring the select/poll/read/write writability event mechanism to drive your writes at the point you get WANT_READ from SSL_write(). But keep watching and processing readability events like normal, but while ignoring writability events after each call to SSL_read() (successful or not) attempt a SSL_write(), if that no longer returns WANT_READ then you can stop ignoring and start using your writability event indication to drive SSL_write() again.
This works but it is only a hack, of course (and may deadlock sometimes if ssl->rstate == SSL_ST_READ_HEADER on both sides of the connection at the same time). What we are doing wrong?
I've not taken in the problem completely here. If this deadlock is correct, can you provide a packet/data dump of the session.
Darryl ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
