[NNTP] Thoughts on article number resetting/rollover
Andrew - Supernews
andrew at supernews.net
Thu Aug 11 19:00:27 PDT 2005
>>>>> "Ken" == Ken Murchison <ken at oceana.com> writes:
Ken> The whole discussion of the 2^32 limit for article numbers and
Ken> rollover got me thinking a little. Rolling the numbers over is
Ken> really no different than if the server unilaterally resets the
Ken> article numbers for some reason (server crash, software
It's actually very different.
The most common cases where article numbers are reset are (in roughly
descending order of probability):
1) the client ends up talking to a completely different server, where
there is no relationship between the old and new numbers at all
(e.g. when a service is outsourced, or the outsource provider is
changed; ISPs are _incredibly_ bad at managing this changeover, and
will almost never give users any warning)
2) the group is reset completely on the server with all articles
removed, and the numbering reset either to 0 or to some arbitrary
Everything else is likely to be down in the noise; in particular,
renumbering of existing articles within a group is something that
servers as a rule simply do not do.
Ken> We need look no farther than IMAP (which also has a 2^32 limit
Ken> for article/message numbers BTW) for a solution. Each mailbox
Ken> on an IMAP server has a UIDVALIDITY metadata item (usually a
Ken> timestamp). Any time the existing UIDs of a mailbox are
Ken> reset/reordered, the server changes the UIDVALIDITY on the
Ken> mailbox (new messages appended to the mailbox does NOT cause any
Ken> change to UIDVALIDITY). When the client sees a change in the
Ken> UIDVALIDITY, it flushes its cache and re-reads the mailbox to
Ken> get the new message UIDs and contents.
Hard to coordinate this between independent, non-cooperating servers
(see the outsource case above).
Ken> A mechanism like this seems like a pretty trivial extension to
Ken> NNTP (one extra param in the GROUP, LISTGROUP, and LIST ACTIVE
You think you can alter those responses without breaking _every single
client_ in existence?
More information about the ietf-nntp