> Hello,
> > If you call SSL_read, an application-level read function,
> > with a blocking
> > socket, you are asking it to block until it can read
> application-level data.
> Here is information from www.openssl.org:
> -- If the underlying BIO is blocking, SSL_read() will only return, once
> -- the read operation has been finished or an error occurred, except
> -- when a renegotiation take place, in which case a SSL_ERROR_WANT_READ
> -- may occur.
>
> So as you see this is implemented but not exactly :-)
There are a huge number of corner cases I did not address, and it was
not
my intent to be a 100% complete discussion of the use of SSL_read.
Nevertheless, I stand by my analysis of his problem.
He called SSL_read with a blocking socket even though he did not want to
block. SSL_read has no way of knowing that he doesn't want to block because
he lied to it by invoking it as a blocking operation.
There will never be any perfectly satisfactory solution to this problem.
SSL_read has no way of knowing whether he really wanted to block until
application-level data was available or whether he really didn't want to
block -- and short of modifying it to call 'select' before it calls 'read'
each time or save the blocking state of the socket set it to non-blocking
and then set it back, no conceivable implementation off SSL_read can
guarantee that it won't block when called on a blocking socket.
The short answer is, if you do not want your socket operations to block,
you *MUST* set the sockets non-blocking. Otherwise, they can block in a
large variety of corner cases causing your program to fail in unpredictable
and sometimes hard to reproduce ways. This problem is not unique to OpenSSL
or even protocol layered on top of TCP.
It is an error to call an application-level blocking read operation if
you
do not want to block until application-level data is available. It is an
error to assume that application-level data must be available just because
'select' gives you a read hit. You can only be certain that
application-level data will be available if the application-level protocol
ensures it. (For example, if it's SSL over SMTP and you just sent a complete
command that the SMTP protocol ensure specifies requires a reply.)
This is one of a whole host of similar bugs caused by thinking that
blocking sockets can be used in a non-blocking way by using status
functions. There are a variety of reasons this doesn't work. One of them is
that things can change after the status function returns but before you
complete the socket operation. Another (the one that bites here) is that the
status function may not test precisely the same thing the blocking function
waits for.
Unless you are guaranteed that the status function tests precisely the
same
thing the blocking function waits for and you are further guaranteed nothing
can change in-between when the status function returns and the blocking
operation commences, you are *not* guaranteed that a blocking operation will
not block and it is *error* to assume so.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
