Newsgroups: news.software.b Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: C news meets a mailing list Message-ID: <1989Aug13.001906.27932@utzoo.uucp> Organization: U of Toronto Zoology References: <1989Aug7.060124.8135@indetech.uucp> <1989Aug8.154631.2816@utzoo.uucp> <1989Aug10.221915.15905@indetech.uucp> Date: Sun, 13 Aug 89 00:19:06 GMT In article <1989Aug10.221915.15905@indetech.uucp> david@indetech.UUCP (David Kuder) writes: >>>... In B I used "recnews"... >> >>If you look at the newsmail(8) manual page, you'll see our equivalents. > >...newsmail(8) I did see those but had interpreted them as transport >mechanisms and not gatewaying programs. In particular recenews and >recpnews both presume that they are recieving mail that has been >encoded... As did B recnews, unless my memories are much mistaken. Recpnews is meant to be fully compatible with B recnews (which, incidentally, is a *lousy* transport mechanism and not a particularly good gateway). >=>Speaking not being able to see straight. Any ideas were nearly empty >=>batches might be generated? We send out the occasional cunbatch script >=>wrapped around the magic that says 12 bit compressed and zero actual >=>data. >> >>Is it causing problems? It's a normal occurrence if you have stuff >>expiring quickly enough that the batcher sometimes can't find any of >>the articles that are supposed to go into a batch... > >... Those error messages that down stream sites send back >consume my time. The sending of the empty batches and the error messages >consume phone time even with a telebit. An empty (or short) UUCP >batches chew up a space on the UUCP queue... Mmmm, yes, you're right. A partial fix, which will appear in the next patch, is for newsrun to ignore batches which are empty after decompression. That at least eliminates the error messages from C News sites. >... Since >these batches are short the queue length isn't an accurate >representation of how much news is queued to go out... One change some people have made is to measure queue length in bytes rather than batches. It's an interesting idea that may eventually become official. >... The feedback here >could end up with a site that managed to be just slow enough >guarenteeing that it never actually got any news. Such a site is probably too slow to be getting a full feed. It is necessary to have a reasonable speed margin in hand, even in the absence of such problems; news traffic is very bursty, and a site which is only barely fast enough is going to have continual trouble. >... My guess it that a check for empty batches in the >sendbatches pipeline after the muncher runs will be liveable... Possible but awkward, given that it will mean buffering onto disk so you can check the size of the whole batch and then decide what to do. There really isn't any very graceful way out of this one; the only real fix is to smush together several of the currently-separate functions in batching, so that batch preparation and splitting can interact. -- V7 /bin/mail source: 554 lines.| Henry Spencer at U of Toronto Zoology 1989 X.400 specs: 2200+ pages. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu