This is the beta test version 0.8.3 of the new INN feeder program `innfeed.'
It is written in ANSI C. The features of it are:

	1. Handles the STREAM extenstion to NNTP.
	2. Will open multiple connections to the remote host to parallel
	   feed.
	3. Will handle multiple remote hosts.
	4. Will tear down idle connections.
	5. Runs as a channel/funnel feed from INN.
	6. Will stop issuing CHECK commands and go straight to TAKETHIS if
	   the remote responds affermatively to enough CHECKs.
	7. It will go back to issuing CHECKs if enough TAKETHIS commands fail.

Read the rest of this file and then read and apply the instructions in the
the INSTALL file.


Bugs/Problems/Notes etc:

	1. There is no graceful handling of file descriptor exhaustion.

	2. On the stats logging the 'offered' may not equal the sum of the
	   other fields. This is because the stats at that moment were
	   generated while waiting for a response to a command to come back.

	3. innlog has not been fully fixed to deal with the new logging
           information generated by innfeed.

	4. If innd flushes the input to innfeed while one of innfeed's
	   peers is hung, then you may have multiple innfeeds running
	   together. The original one will be stuck trying to send its last
	   article out before it tries to send the QUIT. Eventually the
	   read for the reponse to the outstanding command(s) will timeout
	   and the connection will be torn down and the innfeed will
	   exit. In this case multiple innfeeds will not step on each other
	   as the first one will close all backlog files and release all
	   locks immediately when innd closes the input.  

	5. If innfeed is killed (like with a signal), but innd doesn't
	   wait() on it fairly quickly, then the lock will not be released
	   and successive innfeeds will complain and fail to run. The lock
	   file mechanism will be cleaned up in a later release. For now,
	   always use ctlinnd to refresh or stop the innfeed process 
	   ('flush', or 'drop')

	6. If all the Connections for a peer are idle and a new tape file
	   is dropped in by hand, then it will not be picked up until the
	   next time it gets an article from innd for that peer. This will
	   be fixed in a later version, but for now, if the peer is likely
	   to be idle for a long time, then flush the process.

	7. Adding a tape file by hand does not cause extra Connections to
	   be automatically created, only the existing Connections will use
	   the tape. If the extra load requires new Connections to be built
	   when innd delivers new articles for tranmission, then they too
	   will use the tape, but this a side effect and not a direct
	   consequence. This means if you want to run in '-x' mode, then
	   make sure your config file entry states the correct number of
	   initial connections, as they're all the Connections that will be
	   created.
	  
	8. If '-x' is used and the config file has an entry for a peer that
	   has no batch file to process, then innfeed will not exit after
	   all batch files have been finished--it will just site there idle.

	9. If the remote is running inn and only has you in the nnrp.access
	   file. The innfeed will try every 30 seconds to reconnect to a
	   server that will accept IHAVE commands. i.e. there is no
	   exponential back of retry attempt. This is because the
	   connection is considered good once the MODE STREAM command has
	   been accepted or rejected (and nnrp rejects it).

Futures:

	1. Innfeed will eventually take exploder commands.

	2. The config file will be revamped to allow for more global
	   options etc and run-time configuration. Too much is compile-time
	   dependant at the moment.

	3. innlog will get fixed up.

	4. The connection retry time will get more sophisticated to catch
	   problems like the nnrpd issue mentioned above.

Changes for 0.8.4
	
	1. A change in the connections in order to
	   encourage connections that were opened due to spike, to close
	   down sooner than before.
	2. The backlog files are no longer concatenated together at process
	   startup, but the .input is simply used if it exists, and if not
	   then the hand-dropped file is used first and the .output file
	   second.
	3. The innfeed.status is no longer updated by a innfeed that is in
	   its death-throws.
	4. Specifically catch the 480 response code from NNRPD when we try
	   to give it an IHAVE.
	5. The connection reestablishment time gets properly increased when
	   the connection fails to go through (up to and including the
	   reading of the banner message).
	6. Bug fix that occasionally had articles sit in a connection and
	   never get processed.
	7. Bug fix in the counter of number of sleeping connections.
	8. Bug fix in config file parsing.
	9. Procbatch.pl included.

Changes for version 0.8.1

	1. various bug fixes.
	2. core files generated by ASSERT are (possibly) put in a seperate
	   directory to ease debugging are

Changes for version 0.8

	1. The implicit state machine in the Connection objects has been
	   made explicit.
	2. Various bug fixes.

Changes for version 0.7.1

	1. Pulled the source to inet_addr.c from the bind distribution.
	   (Solaris and some others don't have it).

Changes for version 0.7

	1. The backlog file mechanism has been completely reworked. There are
           now only two backlog files: one for output and on for input. The
           output file becomes the input file when the input file is
           exhausted.
	2. Much less strenuous use of writev. Solaris and other sv4r
           machines have an amazingly low value for the maximum number of
           iovecs that can be passed into writev.
	3. Proper connection cleanup (QUIT issued) at shutdown.
	4. A lock is taken out in the tape directory for each peer. To feed
           the same peer from two different instances of innfeed (with a
           batch file for example), then you must use another directory.
	5. Creating a file in the tape directory with the same name as the
           peer, the that file will be used next time tapes files are
           processed. Its format must be:

		pathname msgid

	   where pathname is absolute, or relative to the top of the news
           spool.
	6. More command line options.
	7. Dynamic peer creation. If the proper command line option is
           used (-y) and innfeed is to told to feed a peer that it doesn't
           have in its config file, then it will create a new binding to
           the new peer. The ip name must be the same as the peername,
	   i.e. if innd tells innfeed about a peer fooBarBat, then
	   gethostbyname("fooBarBat") better work.
	8. Connections will be periodically torn down (1 hour is the
	   default), even if they're active, so that non-innd peers don't
           have problems with their history files being kept open for too
           long.
	9. The input backlog (tape) files are checkpointed every 30 seconds
           so that a crash while processing a large backlog doesn't require
           starting over from the beginning.

Changes for version 0.6

	1. Logging of spooling of backlog only happens once per
	   stats-logging period.


Any praise, complaints, requests, porting issues etc. should go to me:
brister@vix.com.

Many thanks to the following people for help with beta testing
and/or suggestions: 

    Christophe Wolfhugel <wolf@pasteur.fr> 
    Robert Elz <kre@munnari.oz.au>
    Russell Vincent <vincent@ucthpx.uct.ac.za>
    Paul Vixie <paul@vix.com>
    Stephen Stuart <stuart@pa.dec.com>
    John T. Stapleton <stapes@mro.dec.com>
    Alan Barrett <apb@iafrica.com>
    Lee McLoughlin <lmjm@doc.ic.ac.uk>
    Dan Ellis <ellis@mail.microserve.net>
    Katsuhiro Kondou <kondou@uxd.fc.nec.co.jp>
    Marc G. Fournier <scrappy@ki.net>
    Steven Bauer <sbauer@msmailgw.sdsmt.edu>
    Richard Perini <rpp@ci.com.au>
    Per Hedeland <per@erix.ericsson.se>
    Clayton O'Neill <coneill@premier.net> 
    Dave Pascoe <dave@mathworks.com>
    Michael Handler <handler@netaxs.com>

If I've forgotten anybody, please let me know.

Thanks also to the ISC for sponsoring this work.
