Again, thanks for all the pointers, these are really helpful getting me going in the right direction. I am still digesting all of your info, but wanted to discuss this point further, as it almost sounds like a show-stopper:
> be aware that SSL BIO's (and (SSL*) sessions!) are 'threadsafe' in the sense > that OpenSSL *assumes* a (SSL *) or > /any/ BIO remains inside a single thread from the moment it becomes 'active', > i.e. is set up / is going to do some work. As you pointed out, "the IOCP model does NOT tie a socket to a single thread." In fact, I will likely have four worker threads receiving traffic off the wire, hopefully supporting many thousands of simultaneous client sessions, and each client session consisting of multiple command/data submissions. Thus, it is most likely that all of the submissions from a single client session will NOT hit the same worker thread in my application. I have extended the OVERLAPPED object in my app to include things such as session state, and was planning to include a TLSWrapper object there (encapsulates SSL* m_ssl, BIO_pair, etc...) as well so that each client submission during a session will get the same SSL* object. However, this implies that various threads may work on one of my SSL* object during the life of a client session. It sounds like you are saying this is not going to work? Note, my app guarantees any m_ssl object will NOT get picked up by two threads simultaneously, so any given m_ssl object will only get touched by one thread at a time. But are you saying the SSL* object ties itself to the specific thread that set it up? That doesn't make sense to me, so I'm hoping that I'm just reading too much into your statement. Otherwise, it sounds like I would have to setup and tear down the SSL objects every time a client submits data to my app during a single session? (could be hundreds or thousands of separate client submissions during the life of a single client session) Thanks, n8 ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
