This note explains the posting delay some NewsWatcher users experience with some news servers. It is redistributed with the permission of the author, Jerry Aguirre. This problem is also discussed in FAQ #2 in Appendix F of the NewsWatcher user document, which is reproduced below: FAQ #2 Posting takes forever. The status window appears, and the stupid beachball cursor just spins and spins and spins. If I wait a bit and then cancel, my posting seems to go through OK. What's wrong with this brain-dead program, anyway? While NewsWatcher has not yet achieved artificial sentience, it is not completely brain-dead either. This is a server problem, not a NewsWatcher problem. Your server is very, very slow. This is a fairly common problem at some sites which run old versions of servers or misconfigured servers. NewsWatcher takes only a few seconds to send your posting to the server, then it waits for the server to send back the final response that says "OK‹posting complete" or "Error‹something went wrong". NewsWatcher has to wait for this final response so that it can tell you if something went wrong. Things can and do go wrong with postings, like disk full errors on the server or any of a number of other problems. NewsWatcher has to let you know if there's a problem, because otherwise your posting would disappear into a big black hole without your ever realizing it, and that would not be nice. Only your server administrator can fix this problem. For more detailed information, get the following note and show it to your news server administrator: ftp://ftp.acns.nwu.edu/pub/newswatcher/posting-delays-note.txt ------------------------------------------------------------------ Date: Thu, 20 Oct 94 21:58:03 PDT From: jerry@strobe.ATC.Olivetti.Com (Jerry Aguirre) To: j-norstad@nwu.edu Subject: Re: Getting Rid of Posting Delays Newsgroups: news.software.nntp Organization: Olivetti ATC; Cupertino, CA; USA Cc: In article you write: >The problem appears to happen only in the ref. imp. server (nntp), which >sometimes accepts the POST command and the text of the posting, but then >delays for a very long time before sending back the final "OK" or "error" >response. I get lots of mail from my users complaining about this. What >I'd like to do is put a FAQ in my user doc with explicit instructions for >how to fix the ref. imp. server to not do this, so my users can pass the >instructions on to their news administrators. In short, this problem results from running old versions or mis-configuration. Modern configurations just spool postings to a file for later processing. The user gets immedate return but may not see the posting appear til later. The "refference NNTP" is not a full news package. It was orriginally designed as an adjunct to the B news system. It is still used with the C news system. It adds NNTP capability to an existing news system. (INN has its own NNTP code built in.) When NNTP gets an article from xfer or post it envokes rnews or inews to process it. In B news this was the only way to process articles. But hardly anyone runs B news anymore. C news was written to improve performance and generally clean up the code. To get improved performance C news was designed to process articles in batches. Most UUCP sites got their news in compress UUCP batches. The C news article processor would go thu the setup overhead once and then process multiple batches. This was much faster than B new which would run an rnews process for every incomming article. All the locking and parsing of configuration files for each article would really slow B news down. But C news has a problem with posting. The posting program needs to lock access to the news. If lots of batches are running then they could take a while to finish before allowing inews to run. Also C news is not happy with the individual articles that NNTP hands to it. It has to go thu a lot of overhead to just process one article. So, modern versions of the refference NNTP implementation have a configuraton option to not run rnews or inews for every article. Instead incomming articles are put in batch files on disk. After a limit is reached it will start a new batch file. Incomming posts are just spooled to a temporary file. NNTP returns quickly. There were also problems with getting the correct permissions and such from user generated posts which this corrects also. Later, when C news runs its crontab driven job, the incomming posts and new articles are processed. Of course there can be considerable delay between the user posting and the article actually appearing in the spool. Some people run the C news processor (I think it is called "relaynews") every minute. Others have a loop that runs it continuously. So, the answer is to get a modern version of C news, a modern version of NNTP, and to configure them correctly. Actually I think that the recent release of C news is supposed to have built in NNTP code but I have not looked at it personally. INN was designed with different assumptions. It uses a continuous daemon and network connections to communicate with it. It handles incomming feeds directly with no intermidate copying of the articles. Posting with INN can be a little tricky in some configurations but when properly configured the posting is handed off to the INN daemon which handles it along with other incomming news. The down side of INN is that it requres features that C news does not. You must have sockets and having "unix domain sockets" is even better. It really wants to have a working MMAP system call. Also it was designed to trade memory usage against disk and CPU. So it chews up 5-9 Megabytes just for the INN daemon. If you don't have at least 16 Megabyes then just forget it. Jerry Aguirre