Design issues for nntp storage manager

Marco d'Itri md at Linux.IT
Tue May 15 13:17:17 UTC 2001


On May 15, Alex Kiernan <alexk at demon.net> wrote:

 >The header only feed bit is straightforward, but figuring out what the
(Do you have an innfeed version capable of headers feed now?)

 >nntp storage manager token should look like is causing problems.
I'm not sure I understand your question. Why you do not want to request
the articles by Message-ID like dreaderd does?
I think doing this is a *feature* because it allows your reader servers
to request articles from spool servers which are not slaved to your
numbering server and maybe are not even under your control.
Diablo proves this is not slow (it's "just" an history lookup), and it's
usually faster than an overview access or at least as fast as it.

 >Both have the issue of storing which article server a message is
 >stored on (but thats probably easy to throw into the token somehow
 >like cnfs does).
dreaderd does not know the origin of an article and just asks all the
known spool servers in the selected order, and in practice this works
well enough nobody cared implementing something better.
I think the most versatile implementation would do a first match of the
newsgroup name against a list of wildmat patterns like:

alt.*:alt-spool.news.isp.net
alt.binaries.*:bin-spool.news.isp.net
*:text-spool.news.isp.net

And optionally support something like:

pattern.*:XREF

which means "look at the Xref header and request the article from that
server".

 >A hook to rewrite the history for whole articles we received when they
 >got overwritten in a cnfs can would be needed (but not during expire,
 >I think).
In the diablo/dreaderd model readers do not have an history, and I think
this is very convenient.

-- 
ciao,
Marco


More information about the inn-workers mailing list