Ok, this is getting much clearer. Last question (hopefully)...so if an SSL_write gets a WANT_READ, is it ok for the read thread to do an SSL_read before I retry the SSL_write? Does it matter who does the requested operation as long as it is done? Or does the read thread have to wait until the write thread retries the SSL_write when there is data available before it can read anymore data?
And similarly, if the read thread gets a WANT_WRITE, can the write thread do an SSL_write before the read thread retries the SSL_read? If the write thread does an SSL_write before the read thread retries the SSL_read (assuming socket is writable), will it have written whatever data the SSL_read needed to have written? In other words, can the operation specified the WANT_READ/WRITE have to be done by retrying the operation that caused it? > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 16, 2005 3:02 AM > To: openssl-users@openssl.org > Subject: RE: Confusion about SSL_ERROR_WANT_READ/WRITE > > > > Thanks for this explanation. As I read more, I think I am > getting a > > better understanding of this. So unlike normal tcp > connections, where > > a read juts reads, and a write just writes, SSL_read may write, and > > SSL_write may read. > > This is all done under the hood, so I don't need to be > concerned with > > that, except to reissue the call when I get a WANT_READ or > WANT_WRITE > > error. And when I get one of these, I basically just have to wait > > (select/poll or > > whatever) until the socket is readable/writable, then > reissue the call. > > Does that sound right? > > Yes, that's it. If you use socket BIOs, then it all > takes place under the hood. You don't have to worry about it, > but you do have to know that the semantics of SSL_read and > SSL_write are not the same as read and write. > > > And regarding the use of multiple threads, if I protect the > SSL object > > with a lock, that should be fine right? But it sounds like > a single > > thread for both read and writes is the norm. Is this true? And if > > so, other than the fact that I need to co-ordinate access > to the SSL > > obj with a mutex, is there any draw back to using multiple threads? > > Neither is the norm. Some I/O strategies use a single > thread both reading and writing, where that thread may handle > only one connection or dozens. > Some I/O strategies use one thread for all reads to all > connections and one for all writes to all connections. Some > use a pool of threads, any one of which may do a read or > write to any connection at any time. What is best depends > upon the specifics of a given project, primarily the > scalability requirements and the complexity that can be tolerated. > > One common I/O strategy called 'speculative write' > allows whatever thread generated data for a connection to try > to write it immediately. If the write fails with a 'would > block' error, then the connection is added to a poll or > select set to try the write later from an I/O thread. In this > case, you would need a lock because one thread might try to > write to the connection while an I/O thread is reading from it. > > The SSL state machine is not protected against > concurrent accesses to the same connection. So if you have a > situation where you might try to access the same connection > from two threads (the typical case being a read and a write, > but one could imagine others), you will need to associate a > mutex with the connection. > > Semantically, an SSL connection is a single engine and > SSL_read and SSL_write are entry points to that single > engine. This is different from a TCP connection which is > semantically two unrelated byte streams, one in each direction. > > 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]
