Darryl Miles wrote:
> Nanno Langstraat wrote:
>> It turns out that the problem does *not* directly involve
>> SSL_shutdown(), but it *is* attributable to OpenSSL, and specifically
>> OpenSSL's non-blocking shutdown semantics.

>
> Okat thats cleared that up, it is indeed unrelated to the OP of this
> thread. Please move replies (if any) to a new thread .

Done. (slightly reluctantly because bad archiving websites will see it
as a new thread)



> man 3 SSL_want
>
> "Unlike SSL_get_error(3), which also evaluates the error queue, the
> results are obtained by examining an internal state flag only. The
> information must therefore only be used for normal operation under
> non-blocking I/O."
>
>
> Oh so we bypass all considerations and simply look at the "internal
> state flag" because we are expected to be used for a "normal
> operation". Well handling an end-of-stream condition is not a normal
> operation or situation in my book for a start.
>
> So the question remains, is end-of-stream considered an error
> condition ? What does SSL_get_error() return in the situation in step
> 5 above ?


Can we agree on the convention that as long as no OpenSSL call has
returned -1, there is no error condition in effect, at least as far as
the application knows?

This is the case in the 100% CPU problem at hand.


> But more detail is needed over step 2 in exactly what you are saying
> as "process killed" is not the same condition as "TCP shutdown(RD)".
> One results in a unusable socket (for any purpose, be it read or
> write) and the other results in a still usable socket. So you can't
> just get away with lumping those two situations as if either would do.


OK, the remote peer doing shutdown(RD) was an unfortunate entirely
fictional example of me. But I don't see that the issue is really
relevant: the local API confusion between OpenSSL and the application
exists whether the remote side sent a nice SSL shutdown notify message,
the remote process crashed + remote kernel closed the socket, or the
entire remote machine was unexpectedly hit by a 17-tonne meteor.

In all cases the local situation is the same: what OpenSSL calls is a
application developer faithfully following the documentation but not
aware of SSL internal details allowed to make?

Regards,
Nanno


__________________________________________________ ____________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager majordomo@openssl.org