Clifford Heath <[EMAIL PROTECTED]>:
>> I believe that this is now wrong, and alreay was wrong in 0.6.6b. ...
>> if you really want to avoid blocks, you must use non-blocking I/O.
>> Am I right?
> I don't think so. We use select() with blocking I/O on UNIX (async
> select on Windows), and rely on (mostly?) non-blocking behaviour, at
> least after connection establishment (which is blocking in OpenUI
> anyway).
You won't get non-blocking behaviour even when the handshake is
complete and you have a SSL 2 connection (i.e. don't have to be afraid
of renegotiation). The SSL 2 version of SSL_read ends up calling the
function read_n (in s2_pkt.c), which uses a read() loop. The selet()
result is valid only for the first iteration, the second interation
may block despite of what select() said. Now typically you won't
notice this as the TCP peer usually will send data in complete SSL
records so that the loop doesn't block endlessly, but if it stops a
little bit too early it can make your process block. You can avoid
this (if you want) by using non-blocking I/O.
Now if the partner sends an SSL 2 record with content length 0, the
code that called SSL_read will interpret this as EOF. That's not
nice, and I'd prefer a variant that may block instead.
> It's a little ugly - we use approximately the following code in our
> read() function (triggered after select() says it's readable):
> while ((ret_val = SSL_read(ssl, buf_p, len)) <= 0
> && (rbio = SSL_get_rbio(ssl))
> && BIO_should_retry(rbio)
> && LastError() != WOULDBLOCK)
> ;
I don't think you'll ever see EWOULDBLOCK if you aren't using
non-blocking sockets. BIO_should_retry can only mean EINTR in the
situation that you described.
> I believe that this code doesn't ever block, with the proviso that connection
> establishment is already complete. [...]
Sorry. Either you have code that accepts blocking (because the
application protocol you're running on top of SSL is sufficiently
synchronized, e.g. HTTP where there can't be disagreement between both
parties where a request ends, amd you don't have to multiplex for
various concurrent connections), or you'll have to use non-blocking
I/O.
And if SSL 3 or TLS is used, things become more compliated, as
there's always the possibility that a new handshake is started.
So it isn't even obvious what you have to select() for -- you'll have
to let the library tell you what to do.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
