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

[Stan O. Barber]

r.j.letts at salford.ac.uk is not on the ietf-nntp-post list.

-----Original Message-----
From: owner-ietf-nntp at academ.com [mailto:owner-ietf-nntp at academ.com]
Sent: Tuesday, January 26, 1999 7:47 AM
To: owner-ietf-nntp at academ.com
Subject: BOUNCE ietf-nntp at academ.com: Non-member submission from
["Richard Letts" <r.j.letts at salford.ac.uk>]


>From sob at announcer.academ.com  Tue Jan 26 07:46:39 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 HAA01388
	for <ietf-nntp at ANNOUNCER.ACADEM.COM>; Tue, 26 Jan 1999 07:46:39 -0600 (CST)
Received: from metis.salford.ac.uk (metis.salford.ac.uk [146.87.232.15])
	by academ.com (8.9.1/8.9.0) with SMTP id HAA11040
	for <ietf-nntp at academ.com>; Tue, 26 Jan 1999 07:46:31 -0600 (CST)
Received: (qmail 8160 invoked by alias); 26 Jan 1999 13:45:17 -0000
Message-ID: <19990126134517.8159.qmail at metis.salford.ac.uk>
Received: (qmail 2646 invoked from network); 26 Jan 1999 13:39:56 -0000
Received: from ais007.salford.ac.uk (HELO 0080C83FB401) (146.87.1.2)
  by metis.salford.ac.uk with SMTP; 26 Jan 1999 13:39:56 -0000
From: "Richard Letts" <r.j.letts at salford.ac.uk>
Organization: University of Salford
To: ietf-nntp at academ.com
Date: Mon, 25 Jan 1999 18:36:18 -0000
MIME-Version: 1.0
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: 7BIT
Subject: Re: ietf-nntp Re: INN 2.x-CURRENT against a Cyclone server...
Reply-to: R.J.Letts at salford.ac.uk
Priority: normal
In-reply-to: <002701be4882$e7597320$6320fa81 at owlputer.academ.com>
X-PM-Encryptor: QDPGP, 4
X-mailer: Pegasus Mail for Win32 (v3.01b)

-----BEGIN PGP SIGNED MESSAGE-----

Stan O. Barber wrote:

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

suppose I have multiple feeds from different machines and the NNTP
listening processes communicate with each other about which article
they are currently receiving. in this case one NNTP-listener may be
receiving the 400MB gif image, and (in an ideal world) I don't want
another NNTP listener to accept the same article right now. However
If the current transfer fails I'd like to be offered the article
later on from a different source.

RjL

-----BEGIN PGP SIGNATURE-----
Version: PGP 5.5.5 -- QDPGP 2.12

iQCVAwUBNqy5oaSiIc7jUXyJAQFomAP+MU1LaO8EDVZ9aW8ztbupVSa8b3OpFt47
BefVa+DH4ZmUvXqFSBRhvfuxwikmxqT6RuxKlCg67X7FcfI/347U7g8qldz0qhL9
BWnpfnoHOidBVHAn9uI3hykNE9yyY+4OeA+qJFt8dOq8a3yZmK4jlqZtKlGWSbmD
iXNL379D/PU=
=YJ/a
-----END PGP SIGNATURE-----
Richard Letts                      mail:   R.J.Letts at ais.salford.ac.uk
Desktop & Network Services Manager phone:  +44 161 295 5252
University of Salford              fax:    +44 161 295 5888
Great Britain                      mobile: +44 385 275394