> It is possible to use non-blocking SSL_read() SSL_write()
> calls that
> are interleaved, but not without a mutex or a separate
> thread that
> owns all SSL I/O that consumes requests to read/write.
>
> It is simpler to use two SSL connections. SSL is a
> state-machine, not a pipe.
Awesome the former suggestion fits my needs exactly: I have one thread that's
gotta manage N sockets for both read & write and it's pretty agnostic about the
data itself: just wants to push it along. I wasn't sure if it was ok to
interleave but the confirmation is very nice to have.
Can I use two SSL connections over a single socket? That doesn't seem
possible. How are the SSL connections going to synchronize use of that socket?
Two unidirectional sockets is my last resort here... in my experience
unidirectional traffic is horrible for latency and without disabling
TCP_NODELAY, it kills your throughput (assuming you're passing smallish
messages).
--jason
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
