Thoughts on a feed control system

[Jeffrey M. Vinocur]

On 3 Nov 2002, Kai Henningsen wrote:

> 3. Each peer can (by some transport) set, get, and modify a request

I wonder about doing this as an NNTP extension, actually.  The information
flow feels backwards, but it avoids the need for out-of-band communication
as well as some sort of authentication scheme.  I'm imagining this:

    A is feeding B.  A connects to B, and in the initial steps (with
    MODE STREAM and such things) A sends a command to the effect of
    "The feed configuration you've requested has md5 checksum XXXX" to
    which B can respond "Yes, feed with that configuration" or "No, I'd
    like to suggest this new configuration" (multiline response, or 
    something).

The control flow within A would definitely be a bit hairy (for INN, this 
means innfeed would have to communicate back to innd, or something), but 
there are some advantages.  Certainly logistical as mentioned above, and 
also that it reduces the amount of state that has to be stored (and makes 
the loss of that state quite trivial).

We can imagine an implementation where A doesn't even bother writing the
configuration to disk.  The administrative restrictions on the A -> B feed
are of course permanently set by A's admin, and so it's no big deal if A
has to query B for requests each time innd restarts.  Or if A has several
outbound servers, it doesn't have to have infrastructure to forward a
request from B around to all of them; each server will notice the change
on its next connect.


-- 
Jeffrey M. Vinocur
jeff at litech.org