Re: Question on SSL_dup...

2001-12-27 Thread Lutz Jaenicke

On Wed, Dec 26, 2001 at 02:40:12PM -0500, Sankaran Narayanan wrote:
 I am adding TLS support to one of our servers, and for some legacy reasons
 i need to share the main SSL pointer across several threads. in the
 dispatcher thread i use SSL_dup and then allow the worker threads to
 free the dup'ed SSL object when it is done...
 
 however, SSL_write's on the dup'ed object fail (null pointer write). a bit
 of investigation using VCd reveals that the problem s3_pkt.c, function
 do_ssl_write
 the s-s3 object's write buffer is null...
 
 am i missing something or is there a better way to share SSL connections
 across threads? any help is appreciated.

I am afraid that SSL_dup() does not fulfill your requirements.
You can only have one datastream through one SSL object at a time,
so that you cannot have two threads concurrently accessing one SSL object.

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]



RE: Question on SSL_dup...

2001-12-27 Thread Sankaran Narayanan

 I am afraid that SSL_dup() does not fulfill your requirements.
 You can only have one datastream through one SSL object at a time,
 so that you cannot have two threads concurrently accessing one SSL object.
 Thanks. It was fairly trivial to write a reference counted wrapper object
for SSL*, so that i could avoid using SSL_dup and still allow multiple
threads to
do free.

thanks anyway.

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



RE: Question on SSL_dup...

2001-12-27 Thread Jerry Napoli

Out of curiosity, doesn't one also have to lock the SSL* itself against
concurrent access during read/write operations, or does OpenSSL guard it
for the programmer?

thanks,
jerry


-Original Message-
From: Sankaran Narayanan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, December 27, 2001 10:44 AM
To: [EMAIL PROTECTED]
Subject: RE: Question on SSL_dup...


 I am afraid that SSL_dup() does not fulfill your requirements.
 You can only have one datastream through one SSL object at a time,
 so that you cannot have two threads concurrently accessing one SSL
object.
 Thanks. It was fairly trivial to write a reference counted wrapper
object
for SSL*, so that i could avoid using SSL_dup and still allow multiple
threads to
do free.

thanks anyway.

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



RE: Question on SSL_dup...

2001-12-27 Thread Sankaran Narayanan

 Out of curiosity, doesn't one also have to lock the SSL* itself against
 concurrent access during read/write operations, or does OpenSSL guard it
 for the programmer?

sorry if i am spamming with naive questions, but:
  Do i need locking, if all i do is 'read' in one thread (from remote) and
'write' in another thread (to remote)?

  i want to use blocking read so that the reader will be blocked in the
SSL_read call, while i do a SSL_write from my writer (hence locks wont
work) - i did some basic tests, and it seems to work fine.

  should i worry about any race issues? any comment is appreciated.

thanks.

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



Re: Question on SSL_dup...

2001-12-27 Thread Lutz Jaenicke

On Thu, Dec 27, 2001 at 11:33:33AM -0500, Sankaran Narayanan wrote:
  Out of curiosity, doesn't one also have to lock the SSL* itself against
  concurrent access during read/write operations, or does OpenSSL guard it
  for the programmer?
 
 sorry if i am spamming with naive questions, but:
   Do i need locking, if all i do is 'read' in one thread (from remote) and
 'write' in another thread (to remote)?
 
   i want to use blocking read so that the reader will be blocked in the
 SSL_read call, while i do a SSL_write from my writer (hence locks wont
 work) - i did some basic tests, and it seems to work fine.
 
   should i worry about any race issues? any comment is appreciated.

You may run into problems. As soon as a renegotiation takes place,
SSL_read() will also trigger write operations, that may interfere
with the other SSL_write() operations and vice versa.
In most cases, no renegotiation takes place, so you may run your tests
successfully but that is no proof that the concept is correct.

Best regards,
Lutz
-- 
Lutz Jaenicke [EMAIL PROTECTED]
BTU Cottbus   http://www.aet.TU-Cottbus.DE/personen/jaenicke/
Lehrstuhl Allgemeine Elektrotechnik  Tel. +49 355 69-4129
Universitaetsplatz 3-4, D-03044 Cottbus  Fax. +49 355 69-4153
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED]
Automated List Manager   [EMAIL PROTECTED]