ietf-nntp Re: INN 2.x-CURRENT against a Cyclone server...

[Stan O. Barber]

Forwarded because brian at karoshi.ucsd.edu is not in the ietf-nntp-post group
-----Original Message-----
>From sob at announcer.academ.com  Mon Jan 25 10:09:31 1999
Received: from academ.com (root at ACADEM.COM [198.137.249.2])
	by announcer.academ.com (8.9.1/8.9.0) with ESMTP id KAA26955
	for <ietf-nntp at ANNOUNCER.ACADEM.COM>; Mon, 25 Jan 1999 10:09:25 -0600 (CST)
Received: from karoshi.ucsd.edu (karoshi.ucsd.edu [132.239.1.136])
	by academ.com (8.9.1/8.9.0) with ESMTP id KAA00787
	for <ietf-nntp at academ.com>; Mon, 25 Jan 1999 10:09:24 -0600 (CST)
Received: (from brian at localhost)
	by karoshi.ucsd.edu (8.9.1a/8.9.1) id IAA28881;
	Mon, 25 Jan 1999 08:09:18 -0800 (PST)
Date: Mon, 25 Jan 1999 08:09:18 -0800 (PST)
From: Brian Kantor <brian at karoshi.ucsd.edu>
Message-Id: <199901251609.IAA28881 at karoshi.ucsd.edu>
To: inn-workers at isc.org, kondou at nec.co.jp
Subject: Re: INN 2.x-CURRENT against a Cyclone server...
Cc: ietf-nntp at academ.com

[cc'd to the ietf-nntp list because of the best practices recommendation
below]

There is no definite time set for retry of message delivery after receiving
a 436 reply, but because of the practical meaning of the 436 (i.e., "that
article may be in transit on another connection, ask me again after I've
had a chance to receive it"), the time should probably be on the order of
a few seconds.

Many news senders simply requeue the article at the tail of their send
queue; this works because most often the destination *has* received the
article by the time the sender asks again, and so rejects it.

It could be argued that a more correct behaviour is to attempt to preserve
the order of the articles being offered by stalling the queue until the
article is either accepted or rejected.  However, this will ruin throughput
in some pathological cases where these kinds of collisions occur with some
frequency, and it's simply impractical in the case of multiple parallel
connections.

Perhaps requeuing the article, not at the tail of the queue, but an
estimated few seconds back in the queue would be an optimal compromise.
Whether the improvement would be worth the effort is questionable.

What is more to the point, is to ask why a sender is offering the same
article on two channels?  It seems to me that the sending processes have
an interlocking problem: they should not offer the same article to the same
peer at the same time.  I think this could be defined as a bug, and
probably should be included in the NNTP "Best Practices" document.

I also question whether there is any great win in having multiple feeds
open between peers.  Assuming that the programs at both ends are running
at full disk system saturation, there should be no advantage.

An exception to this is when the receiving system has its articles
distributed on different disk systems by newsgroup or group type, and the
feed splits its sending in the same manner.  Because there is some
probability that this will occur unintentionally in a pairing which has
not been explicitly set up this way, multiple overlapping feed channels
can show some improvement over a single channel, but not consistently.
	- Brian