> > Posting is still not working properly (at least from trn, I will try > > a few other readers). Trn hangs after sending the article (probably waiting > > for a reply from the server); a CTL-C makes trn think it failed (the > > dead.article message) but goes back into reading mode; but syslog shows > > a successful post to our outside feed. Weird. It works ok for me from tin and telnet: suburbia:~$ telnet localhost 119 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 200 suburbia.net NNTPcache server V0.87.9UL Jun 2 1996 ready (posting ok). post 340 Ok Newsgroups: suburbia.general,ausnet.support Subject: test From: proff <proff@suburbia.net> test . 240 Article posted > > Could someone please explain what the timeout values really mean > > in the nntpcache.servers file? I guess that the default 12h for active The active timeout (12h) specifies how old the active and active.times from each server are permitted to get before a refetch. Each one of these files for each server is given a hash signature and if the hash signature changes after an update then the new version is written out to disk and a collation of all files of that type (e.g active.server1 active.server2 into active) is performed. The NewsGrp timeout operates in the same manner, but only affects the collation of newsgroups overview.fmt. The reason for the separation is that the newsgroups file changes very slowly over time, and even then the changes are not really important. Changing the active timeout to 1h (one hour) on a server will refetch the active file every hour or everytime a client connects/disconnects whichever is a longer. A 15k group newsfeed has a ~750k active file, so you may not want to pull it through every hour. It depends on how often a given user wants to see if there is new news previously read groups, without explicitly entering them. > > And how exactly is an expire decided on? Will articles (assuming adequate > > disk space) stay in the cache longer than they stay on the feeding server, > > or are they dropped as they are dropped from the feed (ie., if the feed only > > keeps alt.foo for one day, can I keep it in the cache for a week, and how > > do I control how long)? > > Nntpcache has no way of knowing if the master server(s) has expired any articles > it has in cache, so yes you can keep articles longer than your server does. This Well. You're out of date on this luke ;) Everytime a client enters a group, a .tide file is created in the cache which contains (among other items) the lowest article present on the master server. All xovers (well on mod 512 boundaries anyway) and articles lower (older) than this are removed when an expire is run. There is also a master expireyryeyy time which nothing can be older than. The problem with keeping xovers in the cache for articles that are expired on the master server is that when a newsreader fetches xovers, it does it on the basis of the results of the GROUP command, which gives the number, low and high article statistics as per the master servers collection. If we were to work around this then there would be a dichotomy between what is in the xovers and what is on the master server (meaning a lot of the articles you could see, would not be there upon reading). There is one other method, that I'll may try and introduce. fake the output of the GROUP command, and on a group xover readdir() the group and generate a list of cached articles. attempt to pull out the xovers for each from the xover cache then proceed with the xover as normal. The only problem with this is that readdir()'s can be expensive. A pattern matched group expirey configuration system wouldn't go astray either. e.g alt.fan.rms* 10s > > All in all, I think it is becoming a great program and nearly ready for > > commercial use. Just caching the active file is a real bandwith saver > > since many newsreaders seem to want to always fetch it on startup even > > though it is several hundred k. The multiple feed feature is also nice, > > as it allows us to merge arrogant Micro$oft's newsgroups into our real > > newsfeed. How would it handle multiple feeds if the xrefs could overlap? > When I first wrote in the multi-server capabilities all those months ago I set > myself a rule of not assuming that a group with the same name is the same group > on all servers. ie. alt.foo from newsserver1.net is not the same group as alt.foo > from newsserver2.net. It's not possible to ensure this everywhere (eg. article > <message-id> commands), but it seemed like a good rule to keep to, so that people > can do things like get most of their news from one server, except maybe one or > two groups or a hierarchy that seems to be unreliable/censored/whatever from that > server, then nntpcache can be directed to go somewhere else for those groups. This > made things like the posting code more difficult, and is probably why there's still > bugs in that bit of code. Well. The problem here isn't posting (which we have resolved) but caching. Two different servers may supply (same or different) articles which are xposted to the same groups, resulting cross server, differing article count pollution. The only way to resolve this is to treat every xpost to the treatment nntpcache give posts when trying to locate which server should deal with them and discard accordingly. It just means scanning the whole pattern match group list for every xposted group in an article. -- "Of all tyrannies a tyranny sincerely exercised for the good of its victims may be the most oppressive. It may be better to live under robber barons than under omnipotent moral busybodies, The robber baron's cruelty may sometimes sleep, his cupidity may at some point be satiated; but those who torment us for own good will torment us without end, for they do so with the approval of their own conscience." - C.S. Lewis, _God in the Dock_ +---------------------+--------------------+----------------------------------+ |Julian Assange RSO | PO Box 2031 BARKER | Secret Analytic Guy Union | |proff@suburbia.net | VIC 3122 AUSTRALIA | finger for PGP key hash ID = | |proff@gnu.ai.mit.edu | FAX +61-3-98199066 | 0619737CCC143F6DEA73E27378933690 | +---------------------+--------------------+----------------------------------+
