> > 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. [...] The xref issue is a difficult one. The reason it hasn't been addressed is (a) for a typical configuration it is a non-issue and (b) there is a performence hit in re-writing the xrefs. Multiple servers chop up the group space according to group rules. i.e there is a 1:1 correlation between particular groups and particular servers. In the case where you are running local groups, or pulling in specialist groups, it is rare to find crossposts between the two servers, because the organisational and subject domains are typically very different. However, there is a potential for collision with newsreaders that don't examine the hostname in the Xref field, when a message is cross-posted between two servers and the reader attempts to read two or more of the groups involved in the cross-post and those groups are delegated across at least two servers. Some newsreaders *do* examine the hostname in the Xref field (e.g netscape3.0). For those that don't, when a collision event occurs, the worst-case outcome is that there is chance (only a chance, because it is likely that the article number is either a long way in the past, refers to a message already read, or is a long way into the future (although the future will eventully become the present, for a moment at least according to Descate') the newsreader will mistakingly think the user has already read the article in that group, but not in the other group's it may have been cross-posted to. However far more XOVER lines pass into a nntpcache server than individual articles. The overview.fmt's of most news-servers provide clients with Xref: fields. This means a server grouplist scan and re-write for every Xref in every XOVER line. We already re-write XOVER's themselves, in order to translate different overview.fmt's from multiple servers. Fortunately, we can do the rewrite's *before* xover information is cached, and rely on the cache to save our processing bacon. > 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) On the nntpcache development servers (pentium-100 class machines), a 15,000 group list active takes around 5 seconds. If you have listSecurity on, it will take longer due to authentication checks on every group. At 5 seconds a page however, I can only guess that you have logToClient debugging switched on on, or a truely sick machine. It is possible to get this figure down from 5 seconds to around 1.5-2, using a secondary pre-formatted in-memory cache, at the expensive of around 2Mb of memory and some code-complexity. I had thoughts about this previously (as careful readers of nntpcache.config will note), but until now no one has ever mentioned list active speed as an issue, and until people do, I'm not about to introduce this memory overhead. > The current version is better, mostly due to Steinar Haug and Herbert > Xu, Both Steinar and Herbert have made some really nice contributions. My hat is off to them and to all the many other contributors. It's really nice feeling to have people taking the time understand and appreciate your work. I only wish more people would distribute source code freely so this could happen on a broader scale. Cheers, Julian. -- Prof. Julian Assange |If you want to build a ship, don't drum up people |together to collect wood and don't assign them tasks proff@suburbia.net |and work, but rather teach them to long for the endless proff@gnu.ai.mit.edu |immensity of the sea. -- Antoine de Saint Exupery
