|If specified then overrides default "any" newsgroups for hostname. You have to use * for not-exact matching, see RFC977. Different names have to be separated by COMMAS. For example: -g relcom,relcom.*,comp.* . (Dont forget about shell escape with *). Maximum length of this list have to be less than 500 bytes.|
|If specified then overrides default "any" distribution. Using distributions is not recommended - theyre only really included for completeness. Under current NNTP implementations, setting distributions requires the server to open each article, search through for the distributions line and check it against the supplied list. This will not only increase the load on the server substantially, but increase the amount of time for the connection.|
|Maximum physical time to run. Nntpbtr will end run with save an unretrieved articles list after this time expire.|
|If specified then overrides default 25 articles in stack. The stack is used to speedup article transmission, nntpbtr attempt to push stacksize ARTICLE commands to server before first read from it. Also the size of TCP read buffer depends from stacksize .|
|If specified then check mindiskspace free blocks space on disk to continuation. Nntpbtr checks 30000 blocks by default.|
|In case of CNEWS, nntpbtr dont create number of files in in.coming directory greater than maxinfiles (no check by default and if it is 0).|
|-D||Enable debugging. This diverts reporting to stderr and turns on extra debugging output. Additional flags produce more output.|
|-r||Dont use "MODE READER" command to NNTP server. It is the only for future NNTP servers.|
|-k||Dont increase receive TCP buffer, use the system default.|
|-i||Use "incore" version of DBZ library. This option very accelerate the check of article existance in local history data base, but it essential increase the used memory, see dbz.|
|-f||[ connecttimeout ] If connect fails more than connecttimeout or 900 seconds than it is hard error.|
|If specified then nntpbtr check the locking of lockfile in addition to hostname lock. It is used to prevent from working two or more process on the same low throughput physical link.|
The hostname of the remote NNTP server to connect to. This must be
There are one configuration file used by nntpbtr.
The file nntpbtr-<hostname> contains the time when nntpbtr last connected to the NNTP server at <hostname>. nntpbtr can then use this time to pick up all the articles that have arrived at the server since the last session. It may be followed on subsequent lines by a list of message IDs of articles that are to be retrieved from the server in the next session.
The time is in the standart NNTP presentation "YYMMDD HHMMSS". It is the first line of nntpbtr-<hostname> file.
If youll start nntpbtr first, it should ask ALL articles from remote server (most of them would not be requested due to _history_ data base). If you want to get only _NEW_ articles, call first nntpbtr with illegal group name (for example, nntpbtr -g BAD hostname).
When run, nntpbtr will first lock the addition lock files, nntpbtr-<hostname> file and retrieve the start time for the specified server from this file. If the locking is not possible then run stop. If file doesnt exist or bad then 1-Jan-1970 will be used.
The current time will be obtained from UDP/TCP time service of NNTP server to use as the start time for the next session.
nntpbtr will now connect to the NNTP server at the remote host. if the -r option is specified, then a MODE READER command will not be sent. It can be used if you dont shure about the correctness of NNTP server behaviour.
A NEWNEWS request will now be issued, asking for all the articles that have arrived since the specified start time. The server will respond with a list of message IDs. If there is already unprocessed articles list in nntpbtr-<hostname> file then nntpbtr will run through this list at first, before issue a NEWNEWS.
After it nntpbtr moves into an article retrieval stage. It will go through the list of message IDs, check it for non-existence in local history data-base and request them in turn from the server, adding each article to the batch of articles being either stored in the incoming news directory or piped to rnews. When a batch is found to be larger than the maximum size, it will be submitted to the news system.
During retrieval nntpbtr use stacking to speedup the articles read. It send some more commands (default 25) to NNTP server before it do the real read operation. It smooth the data flow from server and support the full usage of high throughput channels with delay (satellite link). For this purpose nntpbtr also increase receive TCP buffer size and it produce large effect with NNTP server on like Ultrix 4.X machines: it has 16 Kbytes default TCP buffers instead of 4Kb.
Once all the articles have been retrieved, the final batch of articles will be submitted and "newsrun" process started. The nntpbtr repeat its runs up to no new news exist in NNTP server. And finaly previously obtained time to use for the next NEWNEWS will be written to nntpbtr-<hostname>. If hard error has occurred, then the message IDs of any unretrieved articles are also written to this file, for retrieval in the next session.
But nntpbtr doesnt suppose the TCP channel breaks as hard error if it is not specified by -f option. It correctly reconnects to NNTP server and continue operation. The invalid answer of NNTP server during handshaking also produce the same. It can lead to hard loop if your NNTP server reject you. But it is implemented due to occasional errors during NNTP server start. The -f option restrict loop up to 900 seconds or connecttimeout time.
In process, nntpbtr monitor the remained disk space and the number of unprocessed CNEWS batch files. It dont overflow disk and attempt to do the wait of the relaynews process work or exit (it is controled by the configuration of nntpbtr during compiling).
Some critical information is logged to syslog and also is copied to stderr.
Nntpbtr returns a series of return codes which may be useful to controlling programs:-0 - Successful completion.
1 - nntpbtr-<hostname> is busy by another nntpbtr proccess.
2 - No disk free space or inodes for news.
3 - Hard error occurred during nntpbtr work.
Leonid Yegoshin <email@example.com>, LY22
rnews(8), dbz(3), relaynews(8),
RFC977 - Network News Transfer Protocol (NNTP),
RFC1036 - Usenet Article Format standard.
|V2.1||NNTPBTR (1)||22 November 1994|