Re: Confusion about SSL_ERROR_WANT_READ/WRITE

[Joseph Bruni]

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]

smime.p7s
Description: S/MIME cryptographic signature