Ok, I read the RFC and I believe I understand it now.
During the 1st call to SSL_connect(), the client sends the Hello
message. Takes very little time and SSL_connect() returns.
When the server replies with the Hello message, the socket becomes
readable. epoll returns and we call SSL_connect() the
Kyle Hamilton:
> OpenSSL is not a true emulation of the socket layer of the OS. It has
> to do more work (public-key cryptography is more work than almost
> anything else outside of physics models), and there is a combination
> of several operations it has to do in the handshake, beyond the
> in
You're missing something. Non-blocking socket I/O is a facility
provided by the OS. OpenSSL can make use of this by taking any
EWOULDBLOCK and convert it to SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. This doesn't help much, it just means that the
program using OpenSSL won't block on a read() o
>
> Setting up an SSL connection requires some computationally intensive
> operations using public key algorithms and some others involving the setup of
> digests and ciphers.
>
Thanks Steve for your response.
I realize that. But isn't the objective of using non-blocking
soket/bio is so that the
On Wed, Aug 05, 2009, Rij wrote:
> Hi All,
>
> I am opening a SSL connection from a client. The underlying socket and
> BIO are non-blocking. I am observing that SSL_connect is executing
> three times before it completes. While the first and the last call
> return almost immediately (less than 1
