> Did you look at my logs with s_client? I'm starting to suspect that the
> correct way to put it is: "there is *spposed* to be no deadlock,
> but there
> is a bug in SSL_read that can make you screwed".
The bug is not in SSL_read. The bug is in the decision to call SSL_read.
There is one important difference between SSL and TCP. A 'select' hit on
TCP guarantees (almost) that there is application-level data to read, so you
can generally get away with following a 'select' hit for read with a
blocking read. However, a 'select' hit on an SSL connection does not in any
way guarantee that there is application-level data to read, so it is an
error to call a blocking read function based solely on a 'select' hit.
For SSL, you can only call a blocking SSL_read if you know from the
application-level protocol that it is safe to block until application-level
data is received. (Just as would be the case with calling 'read' on a TCP
connection *without* a select.)
The error is in assuming that read hit from 'select' guarantees that
there
is application-level data and therefore that it's safe to call an
application-level blocking read function. A read hit from 'select' is *NOT*
justification for calling a blocking SSL_read function. Only knowledge that
it is safe to block until application-level data is received will do.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
