The discussion below wherein the term "you're screwed" is used seems to
indicate that there is a deadlock situation, which isn't the case. There may or
may not be performance issues associated with the scenario/use-case, but
there's no deadlock.
R
-----Original Message-----
From: [EMAIL PROTECTED] on behalf of David Schwartz
Sent: Sat 6/10/2006 1:02 PM
To: openssl-users@openssl.org
Subject: RE: renegotiating problem - connection hanging?
> 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]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
