This is a discussion on Re: Non-blocking SSL shutdown - Openssl ; 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, ...
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?
OpenSSL Project http://www.openssl.org
Development Mailing List firstname.lastname@example.org
Automated List Manager email@example.com