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
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
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.
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
Performance is related to the application. For example, a system
that accepts 10 SSL connects per year has different requirements than
one that accepts 1000 per second. Obviously there is a middle
ground. My point is that theoretical performance differences are
very real in the later case,
On 5/10/2011 2:10 AM, John Hollingum wrote:
I have a service written in Perl, running on Linux that presents a very
simple SSL listener. When this service is hit, it identifies the
connecting node from its certificate/peer address and just sends some
xml to them containing data from some files
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
