You are, as is so often the case, correct. The way you phrase your
responses sometimes blinds me, and evidently others, to the complete
circumstances.
-Kip
On 21 Sep 1999, Dag-Erling Smorgrav wrote:
> Kip Macy <[EMAIL PROTECTED]> writes:
> > This is in no way a rant against FreeBSD, but rather a rant against the
> > attitude that one needs to know about OS internals to run a lightweight
> > server.
>
> Calling what he did to that box "running a lightweight server" is a
> very very wide stretch of imagination. I haven't seen his CLONE
> program and therefore can't speak with 100% assurance, but I've run
> similar experiments against my own servers, so I think I'm entitled to
> make an educated guess about the behaviour of CLONE. It simulates a
> worst-case scenario for an IRC server: open hundreds of connections,
> log on, join a channel, but don't consume the data the server sends.
> This fills up the server's send queues and exhausts its mbuf pool.
> Memory consumption is a quadratic function of the number of clones
> (linear if you just connect without joining a channel).
>
> The worst thing about CLONE is that it's neither a realistic
> simulation of normal everyday IRC traffic (because real IRC clients
> consume data almost as soon as it is sent, and therefore do not fill
> up the server's send queues), nor of a typical attack against an IRC
> server (because a properly-configured IRC server does not allow a
> large number of connections from the same host, nor does it allow the
> send queues to fill up, and is therefore practically immune to this
> kind of attack).
>
> This is what mbuf usage looks like on a real-world IRC server with
> 1800 clients:
>
> root@irc ~# netstat -m
> 2859/9376 mbufs in use:
> 947 mbufs allocated to data
> 1912 mbufs allocated to packet headers
> 180/2466/8192 mbuf clusters in use (current/peak/max)
> 6104 Kbytes allocated to network (11% in use)
> 0 requests for memory denied
> 0 requests for memory delayed
> 0 calls to protocol drain routines
>
> DES
> --
> Dag-Erling Smorgrav - [EMAIL PROTECTED]
>
>
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
