Prabhu S wrote:
> if(l_ssl_err_code == SSL_ERROR_WANT_READ || l_ssl_err_code ==
>SSL_ERROR_WANT_WRITE)
> {
> l_fds=select(sd+1, &filedes_set,NULL,NULL,
&l_connect_timeout);
Why are you 'select'ing for readability even if the library returns
'SSL_ERROR_WANT_WRITE'?
> One constraint is that the SSL connect , data exchange should happen
within
>stipulated time.As such
> when my client is under stress with hundreds of threads trying to
connect
>to server, the select may timeout and return
> with out completing the handshake.
Having hundreds of threads is a telltale sign of extremely poor design.
It
is very silly to have a large number of threads that are all waiting for
various different things. This creates many problems, but the biggest one is
atrocious performance due to the large number of context switches needed to
do a small amount of work for each of a large number of connections.
> Currently my application tries SSL_shutdown() even after select times
out
> in SSL handshake phase.
That's perfectly fine. The SSL engine is not trying to complete the
handshake 'in the background' or anything. It only performs operations when
you call into it.
> Under stress, the application aborts. The stack in core dumps is not
consistent.
> Is it due to calling methods like SSL_shutdown() in cases where
> SSL_handshake process was terminated abruptly.
I don't think so. If you only ever let a single thread touch a
particular
SSL structure, it should be impossible to cause a race. Just make sure one
thread doesn't call SSL_shutdown, SSL_read, or SSL_write, while another
thread is or might be calling one of those functions on the same connection.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
