ietf-nntp Backfill
Alan Barrett
apb at iafrica.com
Mon Jan 6 04:48:55 PST 1997
Rich Salz said:
> I believe that everyone "just knew" that article numbers were just
> monotonically increasing. If this is no longer clear to implementors,
> then the RFC must be fixed.
Requiring article numbers to be monotonically increasing is an undue
burden on implementations. Dealing with non-monotonically increasing
articles at the client side is easy, provided that the overall trend is
for article numbers to increase.
Why it's sometimes difficult for servers to keep article numbers
monotonically increasing:
If a site wants to keep article numbers in synch between a master
and slave server, then one of the obvious things to do (given
today's software) is to run INN in slave mode on the slave server
and use the xreplic extension on the feed between master and slave.
If the feed between master and slave is made up of several parallel
NNTP sessions, or if the list of aticles to be sent is reordered in
any way due to some transient failure, then articles will sometimes
arrive at the slave server out of order.
How a client can easily deal with articles that arrive out of order:
Clients already keep lists of articles that have been read. When an
article does not yet exist on the server, clearly that article has
not been read, and the client should refrain from acting as if the
article has been read. This behavious easily deals with articles
that arrive out of order, but requires the client to maintain an
ever increasing list of read articles. Provided the overall trend
is for article numbers to increase, so that the low water mark never
(or very seldom) decreases, the client can recover storage space by
treating all article numbers below the low water mark as having been
read.
--apb (Alan Barrett)
More information about the ietf-nntp
mailing list