🚀 go-pugleaf

dem>    Also, our news machine has lots of memory.  This is fairly
dem> important for INN.   

bruce> I'd appreciate it if somebody could be more specific about the
bruce> INN memory requirements:
bruce> a)	exactly how much is ``lots''?

   In our case, we have 64 MB RAM and 256 MB swap.  This machine runs
other tasks in addition to INN.

bruce> c)	does ``fairly important'' mean that INN will crash and
bruce> 	burn if it can't malloc  more than 2.5 MB of VM (e.g.)?

   It means your performance will suffer if your system doesn't have
enough memory.  Right now, the innd on our news machine has been
running for one week, and is 10 MB in size.  I suppose a crash and
burn is possible if your machine is really starved for memory.  If you
have less than 16 MB of RAM, you should probably avoid INN.

bruce> Does innd have to be running continuously, or can it be run on an
bruce> as-required basis from inetd (suitable for machines with low
bruce> volume feeds and only occasional newsreader connections (nntpd
bruce> can be run from inetd))?

   innd is built to be running continuously.  It listens to port 119
like inetd would if your were using the standard nntpd.  When another
host connects to this port, innd consults a file to determine if that
site has permission to transfer news, and if so, the transfer is
handled by innd itself.  If the site isn't allowed to transfer, then
innd forks a process specifically designed to serve NNTP news reading,
in.nnrpd.

   So if innd isn't running, no new in.nnrpd's can be started.  But I
don't think the fact that you should run innd all the time makes INN
unsuitable for low volume feeds.

bruce> What other underlying assumptions and requirements exist for
bruce> INN? For example, somebody else claimed that because INN can
bruce> write to a pipe rather than to a disk file, it's performance can
bruce> be better than C news'.

   Both INN and C News (and B News) can write out files that indicate
which articles are to be fed to another site (a "togo" file, in C News
terms).  INN, however, can write this information to a pipe, rather
than to a file.  If the program interested in this information can
read it from stdin, then there's no need to get a file involved (this
is an oversimplification - the reading program might fall behind).
nntplink is such a program, so you can generally avoid the use of a
"togo" file by having innd and nntplink communicate directly.  This
also can give you near-realtime news propogation, since as soon as
innd has finished processing an article, nntplink will be notified and
can begin to transfer it.

bruce> That assumes that a pipe is fundamentally different from a disk
bruce> file, which is certainly not the case for many varieties of the
bruce> UNIX(R) operating system.

   You must have disks that run at memory speeds.  Or else you have
pipes that you can lseek() backwards on.  There *is* a fundamental
difference.  But I don't think that INN's ability to use pipes this
way is, by itself, reason to choose INN over C News.

bruce> Aside from a socket emulation library, what does INN require
bruce> (does it require BSD-hacked signal(3) calls, e.g.)?

   I'll let someone else handle this one.  INN comes "out of the box"
configured for SunOS, so I didn't have to change a thing in order to
get it running.

--
David Myers                                             (513) 865-1343   
Mead Data Central           No news is             Fabrication Systems
P.O. Box 933                 bad news.                dem@meaddata.com
Dayton, Ohio  45401                             ...!uunet!meaddata!dem