Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.bugs.4bsd
Subject: Re: inetd looping detection too short & dummy environ set wrong
Message-ID: <2717@auspex.UUCP>
Date: 15 Dec 89 18:46:58 GMT
References: <73423@uunet.UU.NET> <40987@lll-winken.LLNL.GOV>
Reply-To: guy@auspex.auspex.com (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 33

>  However this wouldn't catch a looping client which was submitting
>endless legitimate requests.  Unfortunately this is an impossible
>situation to detect correctly.

And, if it's truly legitimate, it's not clear what should be done about
it.  It can cause denial of service, but whether this merits having the
service cut off or not is, I guess, a policy question that should be set
by a particular site.  The loop count should, perhaps, be settable from
the command line of "inetd", which at least lets the site choose how
much is too much....

One of the reasons for what may or may not be correctly called "loop
detection" here is to deal with a UDP server that dies before picking
up the packet left for it, causing "inetd" to fire up another copy of
that server, which dies before picking it up, etc..  (This can be
considered a loop, but it's not a case of some program looping
infinitely....)

Checking the exit code (both for a non-zero "normal" exit, and an
exit-by-signal) could help here; that check does require that the author
of the server violate long-standing UNIX programmer habits :-) and
actually take some care to have the exit status reflect the success or
failure of the server, rather than, say, the number of characters
produced by the last "printf" in the program. 

It also would mean that the exit status should *not* reflect whether it
could completely successfully respond to the request - if it failed due
to some error in the request, the failure indication should be sent back
to the client, since the error is then in some sense the client's
"fault" - but should reflect failure only if it's caused by, say, a
necessary file being missing, or corrupted, or something that probably
means *all* requests are doomed to failure (and therefore something that
needs to be fixed on the server machine).