Yes, I think I understand what you are saying. If I get a WANT_READ from a call to SSL_write, that means I need to read some data before I can send. But like you said, there may not be any data to read since the other end may not have sent anything. But I think my problem was that I was thinking in terms of application data. What I failed to realize was that there may not be any application data to read, but if the other end is a valid ssl client, there should have been some ssl protocol data that was sent, that my end needs to read before my call to SSL_write will succeed. Does that sound right?
And since an SSL_read may write as well as read, and SSL_write may read as well as write, then either of these calls would read the required protocol data such that a retry of the call that resulted in the error should now succeed. So eventhough my call to SSL_write resulted in the WANT_READ error, if my read thread happened to do an SSL_read first, it still would have read the protocol data, and my retry of SSL_write should succeed. Am I right? Close? Way off? Ed > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Saturday, April 16, 2005 10:43 AM > To: openssl-users@openssl.org > Subject: Re: Confusion about SSL_ERROR_WANT_READ/WRITE > > You're on the money. This confused me, too. I had a program > that needed to see if there was incoming data, and so I > performed an SSL_read(). I received back a WANT_READ, because > there was no data yet to read. (I'm using non-blocking I/O). > > But then some time later I needed to send data. The logic of > the program was such that I could expect nothing on the READ > side anyway until I had sent something first > (query/response). At first, I thought I was stuck having to > endlessly perform only the SSL_read even though there was no > data available before I would be able to perform my SSL_write. > > I realized that when you receive a WANT_READ or a WANT_WRITE, > you just need to perform the same operation again with the > same parameters, but that does not exclude you from > performing the other operation elsewhere. Just make sure that > two threads aren't trying to do this at the same time on the > same connection. > > > > > > > On Apr 16, 2005, at 10:22 AM, Edward Chan wrote: > > > 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] > > > ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
