From ghudson@MIT.EDU Fri Dec  3 11:22:35 1993
From: ghudson@MIT.EDU
Date: Thu, 21 Oct 93 22:34:11 -0400
To: inn-gurus@uunet.UU.NET
Subject: Limiting readers


Okay, first, my apologies if this is an old issue.  I looked through
the faq contents, and asked a few people who've been on this list for
a while, and didn't find any indication that this has been heavily
discussed.

At times, it may be useful to be able to limit the number of readers;
e.g. today, our news server ran out of swap due to the ~130 nnrpd
processes, and we were forced to shut off all connections for a while.
It may have been more preferrable to limit the number of nnrpds to,
say, 120.  (Whether this is really preferrable is another issue, but
I'd like to talk about implementation.)

After a bit of thought, I decided that this could be implemented
fairly easily in the following manner:

* When you fork off an nnrpd, remember its pid in a table.

* When you get a SIGCHILD, indicating that an nnrpd has died, run
through the list of nnrpds and do a waitpid(pid, NULL, WNOHANG),
paring the table.  (Old BSD-style signal semantics could allow a
SIGCHILD to get lost in this process, but it would get noticed the
next time an nnrpd dies.)

* Before deciding to fork an nnrpd, if there's a limit on the number
of readers, check if the number of readers is too high.  If it is,
send a 400 message to the user and shut down the connection.

My questions:

* Am I missing anything obvious that would keep this from working?

* Is this any better than R$'s approach of having a script start up
nnrpd, and maintain a count of nnrpds using the filesystem?  It seems
to integrate better with existing options (that is, you'd be using a
ctlinnd to set the option, rather than setting a parameter in the
script), and N waitpid()s are probably less expensive than a couple of
filesystem accesses, but I'm not absolutely sure of this.

* Is this potentially portable enough that I should bother sending
patches back to R$ if I implement this?

* (Completely off the topic) On an Ultrix machine, each nnrpd is
around 1MB.  This seems more than necessary.  What's the chief source
of overhead for nnrpd?  I'll scout around for this myself.

Thanks for any replies.

--GBH


From rsalz@uunet.uu.net Fri Dec  3 11:22:38 1993
Date: Fri, 22 Oct 93 13:27:10 -0400
From: rsalz@uunet.uu.net (Rich Salz)
To: ghudson@MIT.EDU, inn-gurus@uunet.UU.NET
Subject: Re:  Limiting readers

90% of the code to do nnrpd-limiting inside innd is already there.
I posted the script because it was quick and easy, rather then try
to throw together a patch.  Here is how I would do it (will do it
when I get time to work on 1.5).

Add a function poitner to the PROC structure.  Change PROCwatch so
it gets teh name of a function to call.  This keeps the SITEdied
stuff working.  Change the RChandoff code to keep a count variable, that
gets incremend on handoffs, then registers the proc with a READERdied
kind of cutnion that decrements the count.

As for big nnrpd's, make sure you are not doing DBZ incore.
	/r$

From stevo@elroy.jpl.nasa.gov Fri Dec  3 11:22:40 1993
Date: Fri, 22 Oct 93 11:31:18 PDT
From: stevo@elroy.jpl.nasa.gov (Steve Groom)
To: ghudson@MIT.EDU, inn-gurus@uunet.UU.NET, rsalz@uunet.UU.NET
Subject: Re:  Limiting readers

> As for big nnrpd's, make sure you are not doing DBZ incore.

If you have mmap() for files (e.g. SunOS), use -DMMAP on the DBZCFLAGS line,
in which case the DBZ incore is irrelevant.  If your system can do it,
this is probably the best way to go.

-steve