Rich Salz <[EMAIL PROTECTED]> writes:
> > Any ideas?
> >
> > More importantly, do you know why this limitation exists at all? I would
> > rather fix the problem than run from it.
>
> The limit exists because the context depends on state derived from each
> half of the duplex connection. (Mythical example, for explanation: SSL
> periodically sends a checksum of all bytes exchanged. Since it was
> designed
> for lock-step protocols, not streaming ones, a simple "sum += byte"
> would
> suffice. Locking that wouldn't be very good.) As for fixing it, with
> all
> due respect, someone who thinks time() is a reasonable seed is probably
> under-qualified to fix an SSL implementation.
Actually, the read and write halves of an SSL implementation don't
share any state. There's no reason why you can't write an implementation
that handles them in different threads without having any thread
locking. This is what PureTLS does.
The major exception is handshake, which does have to be done in
lockstep. Also, you have to make sure that the threads interact
properly during closure.
-Ekr
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
