Unix/Linux Go Back    


BSD 2.11 - man page for nntpxmit (bsd section 1)

Linux & Unix Commands - Search Man Pages
Man Page or Keyword Search:   man
Select Man Page Set:       apropos Keyword Search (sections above)


NNTPXMIT(1)									      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 sys-
	      tems 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 reoffered 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 indi-
	      cating whether the articles was successfully accepted by the  remote  server  (zero
	      exit for success, non-zero for failure).

       The next options set the underlying transport protocol that nntpxmit uses.  The NNTP spec-
       ification assumes a TCP-style transport protocol underlies it (i.e. a reliable,	flow-con-
       trolled,  full-duplex byte stream).  Nntpxmit 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, 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  proto-
       col 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 trying?

       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)
Unix & Linux Commands & Man Pages : ©2000 - 2018 Unix and Linux Forums


All times are GMT -4. The time now is 11:27 PM.