Eric Young wrote:
> 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
This sounds great !
Lets see if I get this right.
If I build a non-blocking app, I can keep on calling SSL_read of
SSL_write during the initial connection handshake and the read/write
calls will return the should retry code as long as the initial handshake
is being carried out. I need to keep calling the read or write routines
to advance the handshake's state machine.
At some point, I will no longer get a should retry code, meaning the
connection is there.
Great, this only leaves me with the question of how to start the
handshake just after the tcp connection setup. (I don't want to wait
with the handshake until I can send some data.)
Can I do this by simply trying to read from the socket or can I call
SSL_do_handshake which will also return the should retry code ?
Thanks !
Jeroen.
+-------------------------------------------------------------------------+
| Administrative requests should be sent to [EMAIL PROTECTED] |
| List service provided by Open Software Associates, http://www.osa.com/ |
+-------------------------------------------------------------------------+
