On Wed, 19 Mar 1997, Herbert Xu wrote: > Duncan Sinclair wrote: > > The only comment I can find in the source is that nntpcache does not > > handle crossposted xovers for disk performance reasons - I don't understand > > this. Can't it just treat xref info like other xover data (modulo the > > changes required for consistency)? I'm not expecting it to record the > > I don't understand, its Xref line should always be the same as the one > obtained from the remote server. Which is one of several reasons some *intelligent* newsreaders have problems with nntpcache... It should *NOT* forward the original Xref line unchanged. There are several different ways of handling it correctly, I will try to enumerate some of them here (it's possible I have missed some, but I don't think so): 1. Change the hostname to it's own hostname. Remove all references to newsgroups it gets from a different server than the server it got this message from. 2. Change the hostname to it's own hostname. Translate the message-numbers for newsgroups it gets from a different server (note that this is *very* hard to in general), deleting any newsgroup for which it couldn't be translated. 3. Remove the Xref line. Alternative 1 is probably the best practical solution, while alt. 3 is the easiest. Alternative 2 looks like it would require a msgid lookup for each article, and it doesn't give much extra (unless you actually contact the other news-servers to do the msgid lookup if you don't already have it, ICK!) The reason you can't just copy the Xref line is that a newsread can try to use it to make sure you don't have to read an cross-posted article more than once. If you try to use nntpcache to merge two (or more) different newsserver you will run into big problems if any message are crossposted between the two sets of servers. The result varies, but includes getting all messages unread again, and never getting any more messages in a newsgroup until you manually edit the .newsrc! I suspect the only reason not all intelligent newsreaders have that big problems with this is that some of the discards the Xref header since it contains the wrong hostname (doing a hostname lookup and discovering that it doesn't match!?) We tried nntpcache but have switched back to a INN server again, the major reasons why we did this was that *MOST* newsreader misbehaved in one way or another, and that the performance s*cked. The Xref thing might be one of the things that gives newsreaders problem, but it certainly isn't the only one, since even newsreaders that ignored Xref info had strange problems, albeit not as strange as trn/strn/trn4... And the performance I'm talking is not just that it doesn't have the information available and have to go and get it, that wouldn't explain why either 'list active' or 'list active <newsgroup>' takes 20-100 times as long as the new INN 1.5.1 server on the same machine, especially not if you did exactly the same operation 1 minute ago!! I'm not exactly sure which of these strn/trn4 uses to list the newsgroups and an approximate number of articles, but this operation could easily take 3-5 seconds for a screenful of newsgroups, 40-50 or so... With the INN 1.5.1 server now in place this takes an almost unmeasurable time-period, we're talking about something like less than 0.1 seconds in most cases! (OK, so page 5 sometimes take 0.1-0.2 sec, unknown why, but then that page sometimes took 5+ seconds with nntpcache) Ooh, I'm sure it will continue to s*ck less for each new version... I first looked at it at 0.87 something (0.87.8?), when I classified it as joke. It keeled over immediately on both SGI Irix and Linux... It wasn't even worth trying to get it to run. My impression of 1.0 is 'public preview', except that Netscape 4 PR1 didn't have that many nasty bug :-) The current version is better, mostly due to Steinar Haug and Herbert Xu, but it's still bad enough that I won't use it if I have a choice.. -- Torbjörn Lindgren E-mail: tl@funcom.com If Santa ever DID deliver presents on Christmas Eve, he's dead now.
