On 3/2/2011 9:55 AM, ikuzar wrote:
3) I come back to the SSL_write( ). He wants to read( ). The doc says : " Caveat: Any TLS/SSL I/O function can lead to either of *SSL_ERROR_WANT_READ* and *SSL_ERROR_WANT_WRITE*. In particular, |SSL_read()| or |SSL_peek()| may want to write data and |SSL_write()| may want to read data. This is mainly because TLS/SSL handshakes may occur at any time during the protocol (initiated by either the client or the server); |SSL_read(),| |SSL_peek(),| and |SSL_write()| will handle any pending handshakes. " 3.1) When the doc says "SSL_write () may want to read data"... what does it mean exactly ? Does it mean that a function is blocked somewhere because it wants read ? ( In my case : this function is accept( ) ?? )
It means that for the SSL_write operation to make further forward progress, the SSL engine must read some data from the connection. Since the connection is non-blocking, it is not blocking. It is somewhat analogous to EAGAIN.
The difference is that you know specifically that it must *read* from the connection. You may retry the SSL_write operation at any time. You could, for example, wait half a second and then call SSL_write again if you wanted to. The ideal response would be to wait until you know data can be read from the other side, for example, by using 'select' or 'poll' to detect readability of the socket.
3.2) Does the client and server share the same ssl object ... ?
I think that question is too vague to answer. Each side has its own software running and tracks the state of the shared SSL connection however it wants. However, if you had trusted shared memory to store a shared object in, what would you need SSL for?
DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org