> Well, 0.87.9 seemed to fix my syslog, trn, and bogus directory problem. > Now it's time for the minor nits. Ah good. I'm not expecting the thing to be completely bug free at this point of course, but I'm glad to hear that things are improving on the whole. > My syslog gets some messages like > nntpcached[4032] connect from charon-gw.spec.com > just like it should, but in other cases it is blank after the 'from'. Does > this mean the reverse lookup failed or that it lost track of where it came > from? Can't say I've ever seen this on any of the machines I run nntpcache on. I can only assume the reverse lookup isn't working properly. I'll have a hunt through the code, but it would help if you or someone could provide some hints as to what sort of circumstances lead to this incorrect behaviour. An exact sequence of steps to show the bug would be terrific. > 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. Oh dear, I'm getting sick of that posting code... Back to gdb then. :-\ > Could someone please explain what the timeout values really mean > in the nntpcache.servers file? I guess that the default 12h for active > means it only fetches a new active file every twelve hours, but what about > the default 24h for NewsGrp (formerly 'other')? Does that mean the tides > are only adjusted once a day? Several people complain that after they read > news, that their readers don't show any new articles for many hours, although > a force read on a group will show the new articles. Will changing NewsGrp > to 1h fix this without causing other problems? Basically, when a client connects, nntpcache checks the mtime of the active/ active.times/newsgroups/whatever and if it hasn't been modified for more than the amount of time specified in the configuration file it will do a recollation, which then involves checking the mtimes of the relevant files from each server (eg. active.news.feed.net + active.localhost merges into the active file), and if the mtimes for _those_ files exceeds the time specified in the configuration file the it will ask the relevant server for a new copy. Note that nntpcache will hand out the existing data then ask the parent daemon to do all the above collation so that noone is stuck waiting for a potentially time consuming rebuilding of active/active.times/whatever while waiting for their newsreader to come up. Personally, I've learnt to read news at least twice, so that the first time it forces an active file reload (if nntpcache deems it's data is too old), then the second time the client actually receives a copy of the updated data. The more people are using nntpcache, the less of a problem this is likely to be. > 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 can create a problem if nntpcache caches the xover information for an article, then the article expires from the server, then a newsreader asks for the article thinking that the article is there because it was able to get xover data for it. I haven't yet found a reader which has a problem with this, and I've certainly seen xovers for non-existing articles coming from real newsservers before, so if therea are any readers that have a problem with this then nntpcache isn't the only thing they'll have problems with. Cache expiry time is set in the nntpcache.config file, which is compiled from the conf.cf file. Hopefully everything anyone could possibly want to configure is in that file. > 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? Funny ya know, it was only a few days ago that i realised that xrefs could overlap. The fix that we implemented was to have nntpcache only cross post to groups that are handled by the server handing out the article. This is really the only way to handle this situation, since there's no way of knowing what the article numbers for a group handled by a different server are. 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. -- Luke Bowker, puke@suburbia.net, puke@deakin.edu.au Suburbia Public Access Network Site Sysadmin "Don't try to understand. Knowing you, I'm probably wrong" - D. Mustaine
