> 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]
