ietf-nntp New wording on article numbers - draft 3

[Ade Lovett]

Chris Caputo writes:
>
>How about not specifying how servers communicate, in terms of article
>ordering, but rather that the server must always present to the client an
>increasing picture of the available article numbers?  If there are "holes" 
>in the article numbers on a slave, it shouldn't show any article numbers
>above the holes until the holes have been filled in. 

Consider the following scenario, with a master-slave replicated feed.
There are three articles in the queue for a particular group, we'll
call them 1, 2 and 3..  and two parallel feeds (either separate
processes, or a multithreaded standalone syncfeeder)

Articles '1' and '3' are assigned to feed-A, and article '2' is assigned
to feed-B.

However, a quirk of fate has decreed that article '2' has been canceled
by article 'x' before it has been transmitted to the slave machines.

Thus only articles '1' and '3' will appear on the replicated slave
machines.

By the reasoning above, without further logic inside the NNTP protocol,
the slaves would then refuse to show any articles above '1', owing to
the hole at article '2'.

Admittedly, such occurances are rare, and can be heavily minimised by
writing single-feed (but multi-threaded, or multi-process) replication
clients, but it does happen, especially in places like the misc.jobs.*
hierarchies, where we tend to see clusters of 30 or more articles
for the same group in the queuefiles, one after another.


However, the issue of replicated feeds is a peculiar one, which a
sizable proportion of the readers of 977bis will not be interested in.

I would suggest that discussion about replicated feeds, for those sites
that require a single-point-of-nntp-contact using multiple machines,
be taken offline, or separated from the issues to hand, where we can
work from the basis of 977bis, and then develop a (possibly entirely
new) protocol, based on NNTP, for master-slave replication.

There are, of course, always alternate ways around providing large-scale
nntp solutions, which don't involve multiple replication, but Clive would
probably be nasty to me if I mentioned them here :)

-aDe

-- 
Ade Lovett, Demon Internet Ltd.