>>>"I'm not sure what you mean by "reader" and "writer", but if you mean
that both threads call OpenSSL functions, you will need to associate a
mutex with each connection to ensure that the >>>reader thread and
writer thread are not trying to manipulate that SSL connection at the
same time."
The reader thread's whole purpose in life is to read(SSL_read() etc)
incoming bytes, make sense out of them
and hand it over to the main() (through queues) and the writer thread
does the exact opposite,
it takes messages from main() and writes it to the socket (through
SSL_write()). Earlier my
socket was blocking type, I read somewhere that it needs to be
non-blocking when renegotiation
is done(or I should have interpreted it incorrectly), so I changed it to
non-blocking and handled
the reads and writes appropriately. Everything works except when I start
to renegotiate and that too
works but fails occasionally (in other words it doesn't work).
Now coming to the first part of your comment. As I understand it, the
manipulation of SSL connection
needs mutex, but can the SSL_read(s) and SSL_write(s) be done from two
threads independently? By manipulation do
you mean only renegotiation and kind or will SSL_read and SSL_write also
fall under that category?
If it is so then how come I never encountered problems till now for
reading and writing through the two
threads (interleaved execution)? The problems came up when I started
doing renegotiation.
Thank you.
>My client and server has two threads each: a reader thread and a writer
thread.
>I have put the renegotiation code in the reader thread. It works for
>most of the time but occasionally the client gets an "Encrypted Alert"
>message ( I suspect that this happens when the application data somehow
>gets
in-between).
>How can I do renegotiation if both my client and server communicate on
>a
duplex
>channel with reader and writer threads?
I'm not sure what you mean by "reader" and "writer", but if you
mean that both threads call OpenSSL functions, you will need to
associate a mutex with each connection to ensure that the reader thread
and writer thread are not trying to manipulate that SSL connection at
the same time.
Unlike a TCP connection as presented by the kernel to user
space, an SSL connection is *NOT* two independent directions. It is a
single state machine.
DS
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
