> Well, we are talking about s_client here... part of openssl executable.
> select() is used with the blocking sockets to make sure that, well, they
> don't block.
It doesn't work that way. The only way to ensure that socket operations
don't block is to set the sockets non-blocking.
> If you call SSL_read on a blocking socket when select says
> it is readable you expect it not to block [forever]. Of course
> it might block
> if there is some data available on the underlying socket but not
> enough to
> complete SSL deciphering, but under normal circumstances it will only
> block until the rest of the record is received. Am I missing something?
Here's a hypothetical. The 'select' function gives you a 'read' hit. You
call SSL_read (thinking there's application-level data, but you don't really
know, do you?). SSL_read reads part of a re-negotiation but has no data to
return to you, so it calls 'read' again (how does it know it's not supposed
to block until it has data?). That 'read' blocks forever because there was
never any application-level data to read. Sorry, you're screwed. You are
blocked in 'read' but the other side is waiting for you to send
protocol-level data.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
