ietf-nntp Issue: number range rollover

Clive D.W. Feather clive at demon.net
Sat Dec 28 13:11:05 PST 1996


Chris Caputo said:
>> Article numbers MUST lie between 1 and 999999999 inclusive [this allows
>> one article per second for 31 years].
> I'd remove the part about one article per second for 31 years.  It could
> be said that a million sites posting an article a day will use this range
> up in 3 years and it would be just as meaningless. 

The point was to indicate that, even at a high posting rate, the range will
last for the forseeable future.

> If we're gonna stick to 32 bits, I'd say we should at least use the full
> 32 bits (1 to 4,294,967,295) to give us slightly more leg room.

Agreed.

> If Usenet (as an example ;-) continues to grow as it has, we may eat this
> space pretty quickly in which case we either need to expand the range to
> 64 bits and/or precisely define how to handle rollovers.

There's no existing practice for handling such rollovers. Here's some
possibilities:

(1) Ignore it. If a server reaches the limit for a group, the server
operator declares a flag day when article numbers in several groups will
be reset.

(2) Assume that, by the time the problem is significant, we can write
977-ter (replacement for 977-bis) to say that 64 bits are allowed (I think
it's too early for that).

(3) Define some mechanism for giving groups epoch numbers. I don't like
this offhand - too much has to change.

(4) Make article numbers be modulo 2^32. Actually, this idea can be
improved on. Divide the number space into 4 quadrants:
    Q0 = 1         to 2^30-1
    Q1 = 2^30      to 2^31-1
    Q2 = 2^31      to 2^31+2^30-1
    Q3 = 2^31+2^30 to 2^32-1
Some time after the low water mark for a group enters Q3 and before the
high water mark is reaching danger, the server should reset the group by
subtracting 2^31 from all article numbers. If the client has a recorded HWM
(or LWM) in Q3, and sees a GROUP response in Q1, it should assume this has
happened and adjust its records in the same way. Obviously, the reset has
to be atomic, but this could be done on Unix by:
    - link each article to its new number
    - change the active file
    - wait for all clients using the old numbers to disconnect (or
      forcibly disconnect them);
    - remove the links with the old numbers.

-- 
Clive D.W. Feather    | Associate Director  | Director
Tel: +44 181 371 1138 | Demon Internet Ltd. | CityScape Internet Services Ltd.
Fax: +44 181 371 1150 | <clive at demon.net>   | <cdwf at cityscape.co.uk>



More information about the ietf-nntp mailing list