Herbert, you are worse than Jaws ;) > Hi: > I found a very small problem with the new attachGroupTalk > stuff. If the remote server is currently out of sync, i.e., > group != group_actual, and we do a group command on that server, then > two successive groups will be sent to the remote server. To avoid this, Aye. I've fixed this. You have to be careful though, because if there is an error, you need to keep scfg->group as it was. > Another minor annoyance with the the current xover implementation > is that xover_input returns whenever it gets '.', and it won't create an > xover file in that case. This can be problematic if people repeatedly > request a section of xover records that has been expired and there's > no xover file to tell nntpcached that it has gone. One solution might > be to move the file creation mechanism to xover_io. Hmm. How often in reality are there holes of over 512 expired articles? _in between_ valid articles? It seems awfully inefficient to have xover bitmaps created for such a situation. > A related bug is that the xover database often contains expired > entries and it never removes them until the timeout for xover is reached. > The timeout maybe much longer than the time that it takes for the remote > article to expire. This is not a problem until there are "gaps" in the > remote newsgroup because of articles with "Expire" set. If that were > so, then the news reader would get the xover records of the expire articles > and think that they actually exist. > > This is not easy to fix. We could add a new timeout called the > listgroup timeout. And if it is reached when we perform an xover nntpcached > will use listgroup to check for expired articles on the remote side. > If we are going to do this, we need to be able to set individual timeouts > for groups which is something we don't have yet. If a site has enough > users, we might get away with removing xover entries when we get a bad > article on an article/body/etc. request. But I don't like either of these > solutions for being messy. So does anybody have a better idea on this? I too have thought about this one. Rather than any sort of pro-active measure my idea was to use the information returned by listgroup and the article commands to continually update the list of articles present on the remote server. This is a pain though, and will require a complex new data structure to handle it - a binary linked list of article ranges for each group. I guess we could chain these onto the current _struct newsgroup_, but memory coherency is going to be a big issue. Just using mmalloc is going to spread the information required for any one group all over the swap, more or less randomly. The best idea might be to have a persistent mmapped offset (rather than pointer, so it is re-locatable) based list in each group directory, although this is going to use at least PAGESIZE (typically 4k-16k) bytes per group with articles (including cross posted articles). Further, it means that each crosspost() is going to have to read in and possibly write out groups*PAGESIZE worth of lists. -- "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 | +---------------------+--------------------+----------------------------------+
