I was not trying to compare O/S, only point out that my experience is
more out of the AIX world than Linux world.
I also want to point out again what I was saying ... you don't need
to make a server and you don't need to fork() and all kinds of
complicated stuff if you write it for inetd. You don't even need to
write socket code (stdin/stdout read/write is all you need). The O/S
will create the processes and clean them up on disconnects and so
forth. Unless you are super performance limited, this is the best
way to go because it always works and is always reliable (if inetd
fails to function on a Unix O/S then the machine is essentially toast
anyway). In addition it is more easily portable if you care about
porting to more than one Unix. Using select is not always supported,
socket flags not always the same, etc. All a non-issue under inetd.
Eric
At 08:57 AM 5/11/2011, you wrote:
On Wed, May 11, 2011 at 08:39:49AM -0700, Eric S. Eberhard wrote:
> I have found that fork() on modern machines as a negligible affect on
> performance and in fact I almost always use inetd instead of
writing my own
> servers, mainly because it is dead reliable, easier to code, and again
> seems to have negligible affect on performance. One would have to do
> millions upon millions of connects to notice or care. Having said that, I
> use AIX mostly, and that performs better under load than Linux on Intel,
> and even Linux on the IBM p series platform. I would do it cheap and easy
> and worry about performance after-the-fact. Eric
Let's not start an OS A is better than OS B discussion here. You can
safely fork single-threaded OpenSSL servers right after accept(3),
and handle the SSL connection in a child. This makes the memory-resident
session cache ineffective, but you can use callbacks to implement an
external (Berkeley DB similar or shared memory, ...) session cache.
Forking after SSL_accept() is tricky, since your parent process will
have partial SSL connections in progress for other clients when a given
handshake completes (event-based connection management) or will serialize
all handshakes, but as you've observed that's not a good option.
So, my suggestion is that a forking server is fine, just use an external
session cache. The Postfix SMTP server is an example of this model. There
before the TLS handshake, we also have an SMTP STARTTLS handshake, but
that does not alter the analysis in any substantive way, just a few more
packets to exchange before the TLS connection is ready.
Note, Postfix is pre-forking, rather than forking, so there is a pool
of processes, that serially accept connections, but this too does not
impact the design analysis.
- You can use a single process with event-based I/O.
- You can use multiple threads in a single process.
- You can fork after accept(2) and use an external session cache
- You can pre-fork and handle clients serially one per process,
with re-use of processes for another client after a client hangs-up.
This too requires an external session cache.
--
Viktor.
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
Eric S. Eberhard
(928) 567-3727 Voice
(928) 567-6122 Fax
(928) 301-7537 Cell
Vertical Integrated Computer Systems, LLC
Metropolis Support, LLC
For Metropolis support and VICS MBA Support!!!! http://www.vicsmba.com
Pictures of Snake in Spring
http://www.facebook.com/album.php?aid=115547&id=1409661701&l=1c375e1f49
Pictures of Camp Verde
http://www.facebook.com/album.php?aid=12771&id=1409661701&l=fc0e0a2bcf
Pictures of Land Cruiser in Sedona
http://www.facebook.com/album.php?aid=50953&id=1409661701
Pictures of Flagstaff area near our cabin
http://www.facebook.com/album.php?aid=12750&id=1409661701
Pictures of Cheryl in a Horse Show
http://www.facebook.com/album.php?aid=32484&id=1409661701
Pictures of the AZ Desert
http://www.facebook.com/album.php?aid=58827&id=1409661701
(You can see why we love this state :-) )
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager majord...@openssl.org
