peter@ficc.uu.net (Peter da Silva) (11/22/89)
News 2.11 PL 14 uses files of the form /tmp/Lmessage-id for lock files. I don't know if thi has been changed in higher patch levels: when I tried to upgrade to PL 17 everything broke, and the list of fixes didn't look important enough to make it worth while figuring it out. When C news gets out of patch-of-the-month mode I'll probably switch to it anyway. But back to the point. Please put the most frequently changing parts of the message-id near the beginning of the id to avoid conflicts... an id like <username.1989nov14.140857@foobar.com> is nearly pessimal. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "I agree 0bNNNNN would have been nice, however, and I sure wish X3J11 had taken time off from rabbinical hairsplitting to add it." -- Tom Neff <tneff@bfmny0>
henry@utzoo.uucp (Henry Spencer) (11/23/89)
In article <7081@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >News 2.11 PL 14 uses files of the form /tmp/Lmessage-id for lock files... In case anyone is planning clever software and is curious, C News does not create any lock based on the message-id. We couldn't see any reason for it. -- A bit of tolerance is worth a | Henry Spencer at U of Toronto Zoology megabyte of flaming. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
coolidge@brutus.cs.uiuc.edu (John Coolidge) (11/24/89)
In article <1989Nov22.180840.1576@utzoo.uucp> Henry Spencer writes: >In article <7081@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >>News 2.11 PL 14 uses files of the form /tmp/Lmessage-id for lock files... >In case anyone is planning clever software and is curious, C News does not >create any lock based on the message-id. We couldn't see any reason for it. I thought of a use, but it might or might not be of value. The idea was not to create a lock based on message-id, but rather write incoming articles into in.coming with the message-id as filename. This works, of course, only if you're _not_ doing C-style batching. We're not, because I'm optimizing for propagation time and want each article out of nntpd and into relaynews ASAP. If you do this, you have a very good indication that article foo has been received by your system if a batch by that name exists, even if it's not in history. Therefore you can turn down future ihaves and cut your dup rate. Pluses: lower dups. Minuses: lower robustness (what if the first copy was munged during transmission or reception), a more complicated naming scheme, more complicated code to deal with ihaves. In any case, I'm not likely to implement this. I'm more interested in doing away with in.coming files altogether and piping things from nntpd to relaynews. Yes, I know of the difficulties inherent in this. But there are some big advantages, and I think I can see a way around most of the major problems (albeit not a truly machine-independent workaround...). --John -------------------------------------------------------------------------- John L. Coolidge Internet:coolidge@cs.uiuc.edu UUCP:uiucdcs!coolidge Of course I don't speak for the U of I (or anyone else except myself) Copyright 1989 John L. Coolidge. Copying allowed if (and only if) attributed. You may redistribute this article if and only if your recipients may as well. New NNTP connections always available! Send mail if you're interested.