Design issues for nntp storage manager

Russ Allbery rra at stanford.edu
Sun Aug 25 23:10:24 UTC 2002


Chiming in on this from the perspective of a year later....

Alex Kiernan <alexk at demon.net> writes:

> Thanks for everyone's thoughts - how about this as a design then:

> Build an NNTP storage token which contains hints as to which storage
> servers contain an article was received from (although for it to
> record receipt from more than one you'd need to change innd).

> Modify SMretrieve to take both Message ID and storage token, since the
> caller always has both anyway. With this information a NNTP storage
> backed could either use the hints from the storage token or poll all
> the servers it knows about (which presumably it'd take from
> incoming.conf and any "extras" which aren't feeding it).

This sounds like the right approach to me, although it's mildly annoying
that this will mean having to find the message ID in the overview
information for each article retrieval.  Hm.  We need to make the message
ID optional (for the use of innfeed, etc.) but just have nnrpd always pass
it.

> Assuming cached articles were fed into a CNFS can, at the point where an
> article was overwritten the history would have to be updated to point
> back to the storage server which contains the article.

I think it's worth including a hash of the message ID as well as the
server hint into the token for articles stored in the cached data type,
since that way we can do a trivial local cache similar to what Diablo
does, storing articles in a directory based on the message ID hash, and
just check it first before retrieving from the remote server.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>

    Please send questions to the list rather than mailing me directly.
     <http://www.eyrie.org/~eagle/faqs/questions.html> explains why.


More information about the inn-workers mailing list