Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
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 ] host-
       name|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	inter-
	      net  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 ac-
	      cept, 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	trans-
	      mitted 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
	      success, 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  de-
       scriptor,  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 net-
	      news 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, nnt-
	      pxmit will send the article, using SMTP [RFC821] text  transmis-
	      sion 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 re-
	      queuing  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  got-
       ten 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  in-
       ews(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)

NAME | SYNOPSIS | DESCRIPTION | THEORY OF OPERATION | FILES | AUTHOR | SEE ALSO | BUGS

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=nntpxmit&sektion=1&manpath=FreeBSD+12.1-RELEASE+and+Ports>

home | help