NNTPXMIT(1)						      General Commands Manual						       NNTPXMIT(1)

NAME

       nntpxmit - transmit netnews articles to a remote NNTP server

SYNOPSIS

       nntpxmit [ -a ] [ -d ] [ -s ] [ -r ] [ -T ] [ -F ] [ -D ] hostname|hostname:file [...]

DESCRIPTION

       Nntpxmit  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.

       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:

       hostname|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 hostname is given without an associated file, it is assumed that the
	      hostname	is  also  the  name of the queue file.	If the separator is "::" instead of ":", it is assumed that the remote host speaks
	      DECNET, instead of the default, IP/TCP.

       -s     Toggles reporting of transfer statistics (how many articles we offered them, how many they accepted, etc).
	      Default is ON.

       -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.
	      Default is OFF.

       -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 reof-
	      fered the next time we initiate transmission to them.
	      Default is ON.

       -a     This flag says that the next queue file on the command line isn't a queue file, but is a single netnews article to be transmitted to
	      the remote in a single operation.

	      NOTE:  this  option  causes  nntpxmit to exit immediately after this transfer is done (regardless of whatever else is on the command
	      line), and to exit with a code indicating whether the articles was successfully accepted by the remote server (zero  exit  for  suc-
	      cess, non-zero for failure).

       The  next  options set the underlying transport protocol that nntpxmit uses.  The NNTP specification assumes a TCP-style transport protocol
       underlies it (i.e. a reliable, flow-controlled, full-duplex byte stream).  Nntpxmit assumes that after doing some magic to get  a  descrip-
       tor,  it  can  do  read(2) and write(2) calls (and use stdio) to move data and check for errors.  By default, nntpxmit will use IP/TCP (DoD
       Internet Protocol suite).

       -T     Sets transport protocol to IP/TCP for all remaining transfers (unless reset by other transport flags).  Default transport.

       -D     Sets transport protocol to DECNET for all remaining transfers (unless reset by other transport flags).   NOTE:  using  "::"  as  the
	      hostname/queue filename separator has the same effect.

       -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 nntpxmit through a fork(2).

THEORY OF OPERATION

       Nntpxmit implements an interactive ihave/sendme transmission system.  Roughly, the protocol is

       1.     open the article, fetch out the message-id (required on all netnews articles), and  send	the  command  IHAVE  <message-id>  to  the
	      remote.

       2.     The remote will then say either "I've seen it already" or "please send that article to me."

       3.     If the response was negative, nntpxmit loops back to step 1 and offers the next article (until queue file EOF).  Otherwise, nntpxmit
	      will send the article, using SMTP [RFC821] text transmission conventions (i.e. CRLF line terminators, and dot escaping).

       4.     Nntpxmit 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, nntpxmit will queue this article's filename to be written back to the queue file at the end of the
	      session with this remote.

       If the communcation link should fail (and nntpxmit detects it through a system call error return), nntpxmit 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).

FILES

       /tmp/nntpxmitXXXXXX

AUTHOR

       Erik E. Fair

SEE ALSO

       inews(1),
       RFC977 - Network News Transfer Protocol (NNTP),
       RFC850 - USENET Article Format standard,
       RFC821 - Simple Mail Transfer Protocol (SMTP),

BUGS

       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 try-
       ing?

       While nntpxmit will lock a queue file (your version of UNIX permitting) against multiple invocations of itself, there is  no  locking  with
       inews(1),  which is what writes the queue files in the first place.  Therefore, never use nntpxmit on the queue files that inews(1) writes,
       because two processes writing into the same file without some kind of cooperation will almost certainly trash the file; move them  to  some
       other name that inews(1) knows nothing about, so that you won't lose articles to races between inews and nntpxmit.

       Adding inews(1) compatible locking to the C code would be much more trouble than it's worth, and violates the KISS principle besides.

								   netnews/NNTP 						       NNTPXMIT(1)