Subject: limiting the number of server invocations
To: Manuel BOUYER <bouyer@antioche.ibp.fr>
From: Erik E. Fair <fair@cesium.clock.org>
List: tech-userlevel
Date: 04/24/1997 12:29:04
At 8:21 -0700 4/24/97, Manuel BOUYER wrote:

>Looks great, but also please add a way to limit the number of user if
>this doesn't exist already (didn't look at the man page). It's usefull
>for small servers.

This is useful for any server, particularly since this is the age of denial
of service attacks.

We really only have two ways of doing this generally (and we really should
shoot for a general solution, in my opinion; in principle, a UNIX machine
can be saturated by overloading any network service that forks a child per
client):

1. We add code to each daemon to run independently, and have them each
track how many children they have.

2. We add code to inetd to track the number of extant children for each
service there are (and we remove the if (fork()) exit(0); code from the
daemons so that they don't orphan themselves).

The first solution gives us the problem that inetd(8) was created to solve
in the first place, in addition, it gives us proliferating daemon.conf
files in /etc. The second solution is cleaner (IMHO), but gives us a
refusal problem; if we want to be verbose about service refusal (rather
than just withdrawing the listener and allowing clients to get "connection
refused"), then inetd has to know a little about each protocol in order to
refuse it with minimum overhead.

As a secondary issue, once you limit the number of users that can use any
given service, it's often necessary to enforce equitable access to the
service; I did this once by not allowing more than one client per "network"
(at the time I used natural classful network number; it might make more
sense in the modern world to simply assume a /24 and not worry too much
about the cases that doesn't cover). It worked remarkably well, to the
annoyance of people who wanted to grab all my server's resources. We could
make that an absolute number, or a percentage of the "available slots."

	Erik Fair <fair@clock.org>