Design issues for nntp storage manager

Alex Kiernan alexk at
Mon Jun 4 12:48:13 UTC 2001

Alex Kiernan <alexk at> writes:

> Anyone any thoughts?

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).

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'm really trying to avoid making nnrpd do anything "special",
maintaining the SM abstraction is attractive to me at least. I guess
there's the issue that failure from looking up in the history could
now succeed in SMretrieve, but I guess thats an application issue.

Personally my interest is in the discrete storage server(s) and reader
servers, rather than the general distributed model, but the two
requirements look reasonably similar.

Alex Kiernan, Principal Engineer, Development, Thus PLC

More information about the inn-workers mailing list