Nanno Langstraat wrote:
David Schwartz wrote:
The socket is not and never again will be readable. It's passed on. It's
bereft of life. It's not pinin' for the fjords. Etc.
And more importantly, OpenSSL is the only party who knows this
underlying cause, and SSL_want_read() is the designated channel to for
the application to query the information in order to do a correct
select() or poll().
At kernel/socket level an end-of-stream condition read(fd, buf, 4096)=0
is a permanent readabily event (as signaled by poll/select). Since you
are expected to read it and detect the special case of a return value
being zero as being an EOF and react accordingly.
However this is now what/how I understand SSL_want_{read,write}() to
mean, these are how the situation looks from the opposite end. Meaning
what are the needs of the SSL layer in respect of the BIO layer (below it).
If the SSL layer has uncommitted data it is trying to write to the BIO
layer it will return SSL_want_write()=true.
Maybe this is a workable fix for my SSL_shutdown() problem, where using
the SSL_shutdown()=0 alone is not enough information to be sure the
"shutdown notify packet" was committed to the BIO layer. But if I call
SSL_want_write() after and get back 'false' then I know we're done.
It is unclear from the man page to me what SSL_want_read() indicates,
since in a normal open channel you are always looking for more data,
however the man page sortof indicates that if the SSL layer is in the
middle of processing a packet but is missing the final data then it will
return true, otherwise false.
It is a given that if the channel is open and has no outstanding error
condition then it is always ready, willing and able to process more
received data, as and when it arrives.
The crux tho as David has explained, is that your application observed
an end-of-stream condition from SSL_read(). The SSL_want() man page
indicates it does not account for errors or any other special overriding
circumstances and the values only make sense when the SSL channel is in
a normal condition. I'm sure you will agree that SSL channel is not in
a normal state as soon as it starts handling an end-of-stream in any
direction.
Now *That* would be a broken application. An application like that would
not work right when doing non-blocking plain TCP either.
Urgh. A non-blocking server application that reads telemetry data from
a source would never write anything back the other way.
Darryl
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List openssl-dev@openssl.org
Automated List Manager [EMAIL PROTECTED]
