On Fri, Oct 9, 2009 at 8:45 PM, Oliver Seiler
I wouldn't expect that the number of cores would affect the number of concurrent SSL sockets you are able to accept and handshake; this would seem to be a function of the I/O subsystem of the machine and OS (as seems to be demonstrated by the relatively low CPU usage). OpenSSL itself may be part of the problem. Thanks for the reply. The platform is Linux (kernel 2.6.28). I too suspected that OpenSSL may be serializing its operations, though I feel this should not be so. I will confirm the OpenSSL behaviour by using it in multiple threads and seeing whether it is able to utilize more than one core.
I have an application where I am planning to use boost::asio's ssl streams. There are two parts of the app, the initial connection establishment and ssl handshake is done by boost::asio::ssl and the connection is then transferred to the core application which does the the rest. I have written a prototype using multiple threads and io_services similar to io_service_pool example.
When you say that "the connection is then transferred to the core application", are you saying it is no longer being handled via asio?
Right, the connection is then no longer being handled by asio. I didn't find any way to get the control of the underlying socket and ssl impl object, they are always destroyed by asio. So, I am making sure that the ssl stream object is not destroyed till the connection is alive.