Darryl Miles wrote:
David Schwartz wrote:
If I'm misunderstanding the man page and/or the source code
please speak up.
My man page says:
If the underlying BIO is non-blocking, SSL_shutdown() will also
Yes but what SSL_shutdown() actually does is always return 0
This discussion a week ago made me wonder how SSL_shutdown() could work
in our non-blocking I/O codebase.
I just got around to check, and lo, I found the following code snippet:
// HACK! -- There was a bug where 'ssl-handler' took 100% CPU between remote
// disconnect and local peer close(). This was not investigated to the bitter
// end, but the severe suspicion exists that the OpenSSL library does not
// react properly with a half-open connection (read side closed, write side
open)
// with non-blocking sockets. The following 5 lines are a least-invasive fix.
// The original control flow of the program is still intact, even though a
// part is now short-circuited here.
if (st->ssl_in_closed) {
shutdown(st->local_socket, SHUT_RD); // Tell local endpoint that we don't
read anymore
st->local_in_closed = true; // Fake lack of SSL-output-still-to-be-sent
...
So I can add one more voice to the choir: the current SSL_shutdown() API
appears to give trouble to every non-blocking developer (I remember I
lost serious time noticing + tracking down this 100% CPU bug), and
afterwards things still don't really work right.
With regards,
Nanno
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
