I have a server which reads/writes a socket independently; that is to say, at
the same time (not a request-response model). I note in the FAQ it says I must
not allow multiple threads to use an SSL connection, so clearly if my sockets
are blocking I cannot support full-duplex traffic (because I cannot call
SSL_write while an SSL_read is blocking, for instance).
It's important that I be able to read a packet as soon as one is available, and
at the same time, send a packet as soon as I have one to send... I would not
want to delay the send until a pending read were complete for example.
I'm uncertain whether placing the socket into non-blocking mode will actually
help here: if an SSL_read returns telling me I need to call it again later, is
it alright to go ahead and start a new SSL_write operation?
Also I'm wondering if the limitation of not being able to write/read at the
same time in blocking mode is easily overcome, for example by preventing
re-negotiation (my application is on both ends of the pipe here), or by
replacing the read/write BIOs, or by supplying some magical mutex callback
function or something.
Thanks for any tips,
Jason Pettiss
jpett...@yahoo.com
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
