On Sun, 12 Apr 1998, Jeroen Wortelboer wrote:
> is it possible to split the SSL_accept and SSL_connect functions into
> several others that do not block ?
hmm.. if the socket is non-blocking, SSL_accept/SSL_connect will return -1
and SSL_get_error(ssl,-1) will return
SSL_ERROR_SSL, SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE,
SSL_ERROR_WANT_CONNECT (if the connect BIO is being used), SSL_ERROR_SYSCALL
or SSL_ERROR_ZERO_RETURN.
The _WANT_XXXX errors mean a non-blocking error occured.
> I would like to have an alternative for SSL_accept that would allow me
> to regain control inbetween the SSL handshake frames. I would like to
> wait for each next frame of the handshake with a select statement and
> still be able to react to other concurrent sessions.
The best way to do this is outlined above. The application will keep on doing
IO on the non-blocking socket until a should retry error occurs.
> Is this possible ?
>
> I have been thinking about selecting inside the info_callback but it
> won't solve the problem. (and is ugly)
Definitly a last resort type solution. One thing to remember is that
SSL_connect/SSL_accept are not actually needed anymore, SSL_read/SSL_write
will keep on returning the -1 should retry type errors while the handshake is
happening. One of
void SSL_set_connect_state(SSL *s);
void SSL_set_accept_state(SSL *s);
have to be called on the handle first and
int SSL_do_handshake(SSL *s);
can be called to roll over the handshake without sending data. It is good
practice to use the should retry read/write flags for SSLv3/TLSv1 when using
non-blocking sockets because the SSLv3/TLSv1 session renegotation can occur at
any time which means any SSL_read/SSL_write could be doing a full handshake.
eric
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
