Hi
> Contrast this to the case of multiple processes handling multiple
> connections via select(). In this case, if a programmer simply
> initiates a connection via openssl then I beleive most likely with the
> present design that the process will in fact block
> periodically, but also even when not blocked it will effectively be unable
> to listen for new connections because the cpu will be
> executing crypto code for a large percentage of the time and during this
> cpu intensive phase for many many clocks the
> process will not be in a position to execute select() and therefore it can
> not in fact receive connections.
Right. But who implements a servr side SSL component without using
multiple threads or processes?
[cut]
> Also, I am under the impression that in a multi-cpu computer that passing
> the cpu intensive processing requests to multiple
> dedicated processes is a very good idea because it allows the OS to
> dispatch each slave process to a separate processor
> and in this way the process group moinitoring the incomming connections
> can remain very light weight and hense always
> ready to receive a new connection. Conceptually we end up with a group of
> traffic cops passing the heavy duty work onto a
> group of slaves.
I don't understand why not using threads? Even threads can be distributed
among multiple processors. Nevertheless there are better mechanism
to load balance huge amounts of SSL requests.
If you expect millions of hits a day you can not only provide a single
server with lots of CPU's. You have to distribute the requests
over a certain amount of servers. The use of a distributed session
database allows you to resume sessions.
Regards Rene
--
-----------------------------------------------------------
Rene G. Eberhard
Mail : [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
