DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: T n

⟦4343257bc⟧ TextFile

    Length: 7106 (0x1bc2)
    Types: TextFile
    Names: »nntplink.8«

Derivation

└─⟦9ae75bfbd⟧ Bits:30007242 EUUGD3: Starter Kit
    └─⟦f91e15335⟧ »EurOpenD3/news/nntp/nntplink2.0.0.tar.Z« 
        └─⟦2c70c5e6b⟧ 
            └─⟦this⟧ »nntplink.8« 

TextFile

.TH NNTPLINK 8 netnews/NNTP
.SH NAME
.I nntplink
\- transmit netnews articles to a remote NNTP server
.SH SYNOPSIS
.I nntplink
[
.B \-d
] [
.B \-s
] [
.B \-r
] [
.BI \-X sysname
] [
.B \-T
] [
.B \-F
] [
.B \-D
] [
.BI \-S n
] [
.BI \-C n
] [
.BI \-L n
] [
.BI \-I n
] [
.BI \-E n
] hostname:file
.SH DESCRIPTION
.PP
.I Nntplink
offers netnews articles [RFC850] named in a queue file (a file of
filenames) to a remote NNTP (Network News Transfer Protocol,
[RFC977]) server, transmitting those articles that the remote server
indicates that it does not already have.
.PP
.I Nntplink
only closes the connection when a certain number of articles (50 by
default, settable) have been offered to the remote end since the last
such closure (this allows the other end to log transfer statistics)
.I or
one can request closure to take place when
.I nntplink
has been idle for a certain time.
.I Nntplink
can also be set to exit when it has been idle for a certain time.
.PP
The command line arguments a processed sequentially, and the flags
can thus be toggled several times during one invocation of the
program, by giving the options more than once.
The options are:
.IP hostname:file
The name of the remote host, and the name of the queue file of
articles destined for that host.
The hostname may be an internet address in dotted
format (e.g. 10.2.0.78, [10.0.0.78]).
If the separator is "::" instead of ":", it is assumed that the
remote host speaks DECNET, instead of the default, IP/TCP.

.IP -s
Toggles reporting of transfer statistics (how many articles we
offered them, how many they accepted, etc).
.br
Default is
.B ON.
.IP -d
Toggles DEBUG output on stderr.
This can be used to see exactly what the two systems are saying to
each other, except for the actual article text.
.br
Default is
.B OFF.
.IP -r
Toggles requeuing of failed articles.
A failed article is an article that we (client) offer them (remote server),
they accept, we transmit, and then they report that they "failed"
or dropped the article (i.e. inews(1) on the remote returned non-zero).
If we have requeuing set, we save the list of articles that they
failed on, and rewrite the queue file with them, so that they get
reoffered the next time we initiate transmission to them.
.br
Default is
.B ON.
.IP -Xsysname
This option allows you to watch the News log file, retrieving the article
id from any lines that match
.I sysname
instead of using batchfiles.  It cuts down on the number of disk i/o's
since relaynews (C-news) no longer needs to create batch files for each
of your nntp neighbors.
.PP
The next options set the underlying transport protocol that
.I nntplink
uses.
The NNTP specification assumes a TCP-style transport protocol
underlies it (i.e. a reliable, flow-controlled, full-duplex byte
stream).
.I Nntplink
assumes that after doing some magic to get a descriptor, 
it can do read(2) and write(2) calls (and use stdio) to move data
and check for errors.
By default, 
.I nntplink
will use IP/TCP (DoD Internet Protocol suite).
.IP -T
Sets transport protocol to IP/TCP for all remaining
transfers (unless reset by other transport flags).
Default transport.
.IP -D
Sets transport protocol to DECNET for all remaining
transfers (unless reset by other transport flags).
.B NOTE:
using "::" as the hostname/queue filename separator has the
same effect.
.IP -F
This says that the hostname is a file descriptor number, already
open to a remote server (with some reliable protocol underneath)
that was passed to
.I nntplink
through a fork(2).
.PP
The next options control local and remote statistics gathering.  Remote
statistics gathering requires this end to close the connection, and so
potentially affects performance if there is high latency in establishing
connections.
.IP -Cn
This option requests that the connection be closed temporarily when nntplink
has sent n articles.   Local statistics gathering is controlled similarly by
the -L option.  Default: -C50 (wait until 50 articles have been sent).

.IP -Ln
This option controls how often statistics are logged locally and can be
used to reduce the size of the logs.  By default, statistics are logged
after 50 articles have been sent.  Default: -L50

.IP -Sn
This option controls how long nntplink will sleep between checking for
a queue file to send. By default, nntplink checks the queue file every
two seconds. Setting -S15 (for example) checks for outgoing news every
15 seconds.  Default: -S2.

.IP -In
This option will cause nntplink to close the connection if
the link has been idle for more than n seconds (this is checked at
every sleep interval, see -Sn), and is meant for connections where
connect time is charged.  It is also useful if the remote end wants
to be able to gather accurate statistics that exclude time spent at
this end waiting for work to do (use -I0).  Default: not enabled.

.IP -En
This option will cause nntplink to exit if the link has been idle
for more than n seconds (this is checked at every sleep interval,
see -Sn).  Default: not enabled.

.SH "THEORY OF OPERATION"
.PP
.I Nntplink
implements an interactive ihave/sendme transmission system.
.I Nntplink,
when invoked does not exit.  It will keep looping through the
following protocol loop:
.IP 1.

read the name of a message to send from the batch file, as well as its
message ID, and send the command IHAVE <message-id> to the remote.
.IP 2.
The remote will then say either "I've seen it already" or "please send
that article to me."
.IP 3.
If the response was negative,
.I nntplink
loops back to step 1 and offers the next article (until queue file EOF).
Otherwise,
.I nntplink
will send the article, using SMTP [RFC821] text transmission conventions
(i.e. CRLF line terminators, and dot escaping).
.IP 4.
.I Nntplink
waits for the remote to say whether the article was successfully
accepted or not.
If the answer is negative and requeuing of failed articles is enabled,
.I nntplink
will queue this article's filename to be
written back to the queue file at the end of the session with this
remote.
.PP
If the communication link should fail (and
.I nntplink
detects it through a system call error return),
.I nntplink
will rewrite the queue file with the article filenames of the
articles that it did not transmit (that is, we don't retransmit
stuff we've already successfully sent and gotten back an positive
confirmation that they got it).
.SH FILES
/tmp/nntplinkXXXXXX

.SH AUTHOR
Erik E. Fair (original nntpxmit)

Warren Lavallee (initial changes)

David Alden (even more changes - current maintainer of the sources :-)

Karl Kleinpaste, Fletcher Mattox, Micheal Cooper, Jean-Francois Lamy

.SH "SEE ALSO"
inews(1), relaynews(8)
.br
RFC977 \- Network News Transfer Protocol (NNTP),
.br
RFC850 \- USENET Article Format standard,
.br
RFC821 \- Simple Mail Transfer Protocol (SMTP),
.SH BUGS
.PP
Always requeuing failed articles can lead to beating the remote to
death with a list of articles that he can't accept for come structural
reason.
How many of these have to pile up before you should declare that
something is seriously wrong with the remote system and stop trying?