Eric, you must be really kidding this time :), servers with this architecture are susceptible to dos and what not..am sure for embedded systems where memory is a big limiting factor the best would be async design, also code becomes easily portable in future.
On Wed, May 11, 2011 at 10:39 AM, Eric S. Eberhard <fl...@vicsmba.com>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 > > At 04:46 PM 5/10/2011, you wrote: > > On 10 May 2011, at 4:13 PM, David Schwartz wrote: >> > On 5/10/2011 2:10 AM, John Hollingum wrote: >> >> Pretty much immediately after the accept the program forks a handler, >> >> but the rogue clients must be glomming onto the main process before the >> >> SSL negotiation is complete. >> > >> > Calling 'fork' with an accepted SSL connection has all kinds of known >> issues. The fundamental problem is that there are many operations that must >> occur both before and after the 'fork', for different reasons, and obviously >> can't do both. >> >> You could accept just the TCP connection in the main process and do all of >> the SSL handshake in the forked process (I think >> IO::Socket::SSL->start_SSL() is what you want for that) --- this would not >> be a high-performance approach (no SSL session cache, fork overhead) but if >> it's fast enough it's fast enough. >> >> It's possible to use openssl in a non-blocking, event-driven manner but I >> don't think Perl's SSL modules expose enough of the openssl API to do that. >> >> >> ______________________________________________________________________ >> 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 >
