> Really? I run between 14.5 to 12GB of cached material, and I don't >even notice expiration. I'm running a 4 GB spool and had to set my expiry time to 24h because otherwise the drive would fill and nntpcache wouldn't expire it. This leaves the drive usually 1/4 emtpy, but during busy times I sometimes have to clean by hand to keep the drive from filling. > I don't think you can really store by message-ID. nntpcache needs to >remember that article 123 in alt.test is actually article 456 on server 1, >and article 124 in alt.test is actually article 460 on server 2, etc. >This index needs to be held on a per-group basis. When the GROUP info >times out, nntpcache will have to download new XOVER info up to the new >highwater mark on each server, and toss out duplicates, and add each >article to its group index. Someone had an INN that stored by message-ID (actually MD5 of the message-ID). There is also INN CNFS which stores all articles in one giant file that just cycles. Performance of INN CNFS is out of this world. What CNFS does is in addition to the .overview there is another index file which maps lines in the .overview to offsets in the relevant spool file. Quite simple but very effective. I agree the most difficult task is the article numbering, and to a lesser extent the aggregation of overview info. Anything else one chooses to do is relatively straightforward, or at least has already been done before with good success so there's a reference implementation :-) Evan
