For me, it works only for SSL_read and SSL_write.
As SSL_connect and SSL_accept make several calls to the underlying socket
API, the SSL_ERROR_WANT_READ failure can happen in the middle of the
processing, not just on the first read, so calling it later wont work
because it will restart from the begining of the SSL handshake instead of
continuing from the point it previously failed.
But maybe I didn't understood how to do it right or maybe this problem has
been solved in the latest OpenSSL release.
Nicolas Roumiantzeff.
-----Message d'origine-----
De : Bodo Moeller <[EMAIL PROTECTED]>
À : List: <[EMAIL PROTECTED]>
Cc : "Sean O'Dell"@epsilon.engelschall.com <"Sean
O'Dell"@epsilon.engelschall.com>
Date : samedi 18 décembre 1999 22:12
Objet : Re: Non-blocking I/O help
>Sean O'Dell <[EMAIL PROTECTED]> in ulf.openssl.users:
>
>>[...] SSL_connect, SSL_accept, SSL_read and SSL_write. Apparently, when
the
>> underlying socket is in non-blocking mode, these functions can/may/tend
to
>> behave in a non-blocking way also. What I'd like to know is, how can I
tell
>> when these functions are completed without using a callback of some sort?
>> With plain old sockets, you can use select() to tell when connect() and
>> accept() have completed successfully. Similarly, with read() and write()
>> it's possible to know when data is available/being sent or if the
function
>> would block and to try again. Can anyone describe the behavior of their
>> OpenSSL-counterparts when the socket is non-blocking?
>
>The sequence to use is
> r = SSL_connect/accept/read/write(ssl);
> err = SSL_get_error(ssl, r);
>Then err is one of the following:
>
>SSL_ERROR_NONE
> Operation completed (this happens iff r > 0).
>
>SSL_ERROR_ZERO_RETURN
> The connection was closed (cleanly, i.e. using SSL/TLS closure alerts
> unless you are using SSL version 2).
>
>SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE
> The operation did not complete; call the same function again later
> when select() or poll() on the underlying socket (if you are using
> the socket BIO, e.g. when you called SSL_set_fd) said that data is
> available for reading or that writing is possible.
> Note the SSL_read may want to write data and SSL_write may want to
> read data!
>
>SSL_ERROR_WANT_X509_LOOKUP
> If you have not called SSL_CTX_set_client_cert_cb, this should not
> happen. Otherwise this means that an application callback
> could not complete.
>
>SSL_ERROR_SYSCALL
> Some I/O error. The OpenSSL error queue might contain more information
> (call ERR_get_error or one of its variants until it returns 0,
> ERR_error_string can be used to translate its return values into
> strings; if the first call to ERR_get_error returns 0, then the
> queue is empty). If the error queue is empty, then look at r:
> 0 means an EOF that should not have happened according to the protocol
> (or you'd get SSL_ERROR_ZERO_RETURN). If it's -1, then for socket I/O
> look at errno for details on the error.
>
>SSL_ERROR_SSL
> Protocol error. Look at the OpenSSL error queue.
>______________________________________________________________________
>OpenSSL Project http://www.openssl.org
>User Support Mailing List [EMAIL PROTECTED]
>Automated List Manager [EMAIL PROTECTED]
>
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
