I was also having some problems with SSL_read() and SSL_write(). My application does read and write from different threads. My problems seem to have gone away after reading David's comment that 2 threads can't be reading and writing at the same time on the same SSL connection. So I've added a mutex to the read and write methods, and this seem to fix my problem. Now, the only errors I get are SSL_ERROR_WANT_READ and SSL_ERROR_WANT_WRITE (as expected) whereas before I was also getting other errors.
Ed > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Kumar, Sunil > Sent: Tuesday, February 08, 2005 6:30 AM > To: openssl-users@openssl.org > Subject: RE: Renegotiation 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." > > 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] > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
