Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!munnari.oz.au!mel.dit.csiro.au!yarra!bacchus!david From: david@bacchus.esa.oz.au (David Burren [Athos]) Newsgroups: news.software.b Subject: Re: Up to the minute dial-up newsfeed Message-ID: <1366@bacchus.esa.oz.au> Date: 27 Feb 91 00:14:01 GMT References: <1991Feb26.024320.24820@looking.on.ca> Organization: Expert Solutions Australia Lines: 83 In <1991Feb26.024320.24820@looking.on.ca> brad@looking.on.ca (Brad Templeton) writes: >I have been thinking about setting up a dial-up up to the minute >newsfeed. This would be a dial-up uucp feed which gives you all the >news that's come in to the second of your dialing in. >One idea is to use named pipes. >This sounds ideal, but there's too much that can go wrong. I'll agree with part of that. It doesn't sound ideal, precisely because there is too much to go wrong and the design seems overly complicated. Of course, feel free to correct me. >And of course, it is hard >to figure what to do if the phone call aborts mid-file. Do broken pipe >signals get sent on named pipes? It does not seem so on my system but perhaps >I have not fully checked. If they do, you can handle this one. Bzzt. Seems very system-specific.... >Sending all the news in one batch can be risky if there's a long blockage >that causes a mega-batch. News batches are usually 50 or 100 kbytes for a reason. Most (hehe :-) UUCPs do not have the ability to restart aborted transfers. I cannot see any reason to increase the batch size that outweighs the problems introduced. >Batchers all have a batching limit and of course >you could arrange to uux the pipe several times. After reading the end of the file, UUCP handshakes are required to determine that it was received correctly. Thus your pipe batcher would have to wait for an acknowledgement from UUCP before updating the list of articles to batch. This would require modifications to the UUCP code. That's fine if calling sites see the new setup as a normal batched-news feed, as all the changes are at your end. That said, I'd prefer to see (if this whole scheme is really necessary) a solution that was more general, and easily implemented across a variety of systems. >Another idea is to change uucp's shell from uucico to a wrap-around program >that starts up the batcher in the background and then calls uucico. Only >problem is that if uucico is too fast, it will quickly decide there is no >work to do and hang up before the first batch is queued by the batcher. One >could delay the start of uucico until the first batch has definitely made >it, but this is not a great idea, and wastes phone time. >Of course, many solutions are possible with the source to uucico and >custom patches. I don't have that, so am interested in more general >alternatives. How do you propose to cope with news that comes in while the batching and transfer is in progress? This boils down to how often the is site calling up... If it's going to call again soon, there shouldn't be a problem. If it only calls sporadically, why not batch news for them on an hourly (or an arbitrary N minutes) basis. If they miss out on news that came in during the last n (Any ideas? Why do you want this scheme? Is it because you don't want to keep batched news around for lots of sites, waiting until they call, and chewing up disk space? You could modify the above suggestion so that the periodic batcher only makes one batch (none if one is already there). Hope this feedback is of use... - David Burren (david@bacchus.oz.au) (athos@eyrie.oz.au)