Ofer Avitzur wrote: > Hi > I am trying to add openssl to my multithreaded client application (on > linux). Currently my application sends data (over tcp socket) from one > thread and read incoming data on another thread. > Does openssl allow writing/reading from 2 different contexts ? > What is the recommended way to implement a client that can send and > receive > data from openssl socket without interdependency between read and write > operations. ? Should I have one thread responsible for both read and > write > operation and pass write data to this thread using some sort of message > queue ?
OpenSSL is fine with reads coming from one thread and writes coming from another, so long as all operations are non-blocking and you don't do a read and a write on the same SSL connection at the same time. If you don't know exactly what you're doing though, I'd strongly recommend using only a single thread for both reading and writing though, there are some traps you can fall into if you try to use two threads. The classic failure case is this one: 1) A renegotiation is in progress. Your side is waiting to receive a final chunk from the other side to complete the renegotiation. 2) You call SSL_write in thread A. You get an 'SSL_WANT_READ' because it cannot write until it reads the renegotiation data. 3) The renegotiation data is received. 4) You call SSL_read in thread B. You get an 'SSL_WANT_READ' because it completed the renegotiation but got no application data. 5) Thread A calls 'select' (or 'poll' or whatever) waiting for a read hit because that's what OpenSSL told it to in step 2, but it is waiting for renegotiation data that already arrived. Boom. An SSL connection has one, and only one, state. Thread A should not assume that the 'SSL_WANT_READ' is got in step 2 is still valid by step 5 because the SSL_read attempted by thread B may have made forward progress. DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
