Xref: utzoo news.software.nntp:420 news.software.b:3568 Path: utzoo!utstat!jarvis.csri.toronto.edu!rutgers!mit-eddie!bu-cs!snorkelwacker!think!gem.mps.ohio-state.edu!brutus.cs.uiuc.edu!coolidge From: coolidge@brutus.cs.uiuc.edu (John Coolidge) Newsgroups: news.software.nntp,news.software.b Subject: Re: Survey: C News batching vs. nntplink Summary: Hmm. Message-ID: <1989Nov20.050245.27641@brutus.cs.uiuc.edu> Date: 20 Nov 89 05:02:45 GMT References: <1989Nov20.002159.26404@brutus.cs.uiuc.edu> Sender: news@brutus.cs.uiuc.edu Reply-To: coolidge@cs.uiuc.edu Organization: U of Illinois, CS Dept., Systems Research Group Lines: 43 wesommer@athena.mit.edu (William Sommerfeld) writes: >Funny you should notice. As it turns out, nntplink doesn't have to >change; only nntpd need change. Patches aren't available yet (and >might not be; I'm really busy; don't even ask for them), but the >changes are simple enough to describe: Yup, this is my opinion too. Really, there's nothing that nntplink _could_ do differently to fix the problem (except close the connection, but then what's the point :-) ). >- I made nntpd aware of the NEWSCTL/LOCKinput lock file. If relaynews >is running, this lock file exists. I rearranged the code in batch.c >to queue the batch into NEWSARTS/in.coming *first*, and only fork/exec >newsrun if relaynews isn't running. I've dispensed with nntpd forking off newsrun a long, long time ago. It turned out to be moderately costly, and (much worse) crashed our machine on a regular basis (something about having big things forking off from inetd-invoked code doesn't make SunOS4.0.3 very happy. Portmap died on a regular basis...). Of course, I've got something to take the place of newsrun, and most people don't (if I had the time to get things stable, it would help...). >If articles are flowing in a continuous stream (less than a >five-second delay between articles), they get batched using the >existing rules (five minutes or 300KB, whichever comes first). This is what I'm trying to avoid, however. My optimal situation is to have each article received back on the outgoing wire with no delay at all. That's impossible, but sub-30 seconds is a very reasonable approximation of the goal. This requires things to happen very quickly, which sort of blows batching away. It's good, though, for people (most of them, I suspect) who consider rapid propagation a secondary goal. --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.