Re: Multiple threads handling one connection

[Bodo Moeller]

Oliver King <[EMAIL PROTECTED]>:

> [...]  Does OpenSSL support reading from a connection on
> one thread and writing to the same connection on another thread?

> Has anyone tried this, or is it not supported?

I would not recommend trying, there is no locking done on the
structures, so the two threads could interfere with each other in
unpredicatable ways.  In the initialization of threaded OpenSSL
applications you'll notice that the application has to provide a
number of mutex locks; however all of these are global locks and there
are no per-object locks, so locking during all SSL I/O functions would
be very inefficient.  If your application has its own locking to
ensure that never two threads will try to use the same SSL connection
at the same time, then there should be no problem.
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Multiple threads handling one connection

[Geoff Thorpe]

On Wed, 16 Feb 2000, Oliver King wrote:

> Hi,
> 
> I sent the message below last week, asking about multiple threads accessing
> a single SSL connection, but didn't receive any replies. I can't find
> anything relating to this on the list archives.
> 
> Has anyone tried this, or is it not supported?

For an unrelated reason I'd heard that sharing of an SSL "object" across
threads was not recommended ... in my case it was the scenario of having
each thread running one or more SSL objects, but a separate thread keeping
an eye on all of them for various stats and monitoring.

However, the synchronisation in OpenSSL seems to happen at a type scope
rather than an object scope (somebody please correct me if I'm wrong). Ie.
there are locks like CRYPTO_LOCK_509 that are used when synchronising on
X509 operations - however they're global and not bound to the object being
accessed. You can certainly ensure your app is thread safe when accessing
SSL objects by;

(a) upping the reference count on the SSL object each time you have a
distinct thread that will access it (this means it will not be deallocated
until each thread has free'd it's own reference) by doing;
   CRYPTO_r_lock(CRYPTO_LOCK_SSL);
   your_x509_pointer->references++;
   CRYPTO_r_unlock(CRYPTO_LOCK_SSL);

(b) wrapping up all calls to your SSL object with the same locking.

Of course, this would probably be next to useless if most of your threads'
job is to perform operations on the SSL object, as they'd all be
serialising up behind each other. If they only touch the SSL object
occasionally this may be the way to go?

Otherwise, looking at SSL_write (and the various "method" functions it
calls) reveals that there doesn't appear to be any locking implicit, so
you'd have to synchronise it all yourself no matter how you decide to go.
On the bright side, each SSL object has an "ex_data" member which is a
CRYPTO_EX_DATA structure used for storing "application data" ... if you
want to put some kind of synchronisation in on your SSL "objects" then you
could perhaps utilise that to store pointers to mutexes or whatever. NB:
Each SSL_CTX object has one of these ex_data things too if that helps :-)

Good luck,
Geoff


--
Geoff ThorpeEmail: [EMAIL PROTECTED]
Cryptographic Software Engineer, C2Net Europehttp://www.int.c2.net
--

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]

RE: Multiple threads handling one connection

[Oliver King]

Hi,

I sent the message below last week, asking about multiple threads accessing
a single SSL connection, but didn't receive any replies. I can't find
anything relating to this on the list archives.

Has anyone tried this, or is it not supported?

Thanks
Ollie King
Data Connection Ltd.

-Original Message-
From: Oliver King 
Sent: Thursday, February 10, 2000 10:33 AM
To: '[EMAIL PROTECTED]'
Subject: Multiple threads handling one connection


Hi all,

I've seen (and written) test programs that drive a number of SSL connections
from multiple threads, but none of them seem to drive a single connection
from more than one thread. Does OpenSSL support reading from a connection on
one thread and writing to the same connection on another thread?

I wrote a simple test app to try this using non-blocking sockets and it
seems to work, but rather than rely entirely on my test I'd like to have a
more definitive answer as to whether or not this is acceptable. If it turns
out that this is a Bad Thing to do, what's the recommended alternative?

Thanks in advance
Ollie King

__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]