[NNTP] 64-bit article counter extension strawman

[Matthias Andree]

"Andrew - Supernews" <andrew at supernews.net> writes:

> If you assume unchecked exponential growth at a rate extrapolated from
> past growth in each specific group, then we have maybe 10-20 groups
> that are likely to run into problems within the 5 to 7 year timeframe
> (none sooner). It's worth noting that if those assumptions hold, then
> the feed volume at that time will be perhaps 48 TB/day, and the
> busiest groups will be getting on the order of 10 million
> articles/day, which has obvious implications for any scheme based on
> resetting article numbers. (It also means that downloading the
> overview alone for one such group will consume 4GB of transfer per
> day, taking half an hour or so even at 20 megabits.)
>
> It's obviously debatable how useful these assumptions are.

...and how usefuls groups with 10^7 articles/day (that's 100 per second)
are and who is going to read them in 10 ms...

> On the other hand, I would be quite astonished if there were more than
> two clients in existence that allowed for 64-bit article numbers,
> especially given that there are no servers generating such numbers.
> Given the extent to which existing clients break at 2^31 or 2^32, it
> is clearly unwise for servers to do so.

Here's another assumption: a client that uses the "unsigned long" C type
(or equivalent in other languages), anything that is the natural word
size of the system, will transparently support 64-bit numbers when
compiled for 64-bit - and this magic "64" has been at least sort of
natural type for ages. Same for the server, even more likely there.

> So there are several (non-independent) choices:
>
> 1) Leave the issue for now and work on it for Draft Standard. This is,
> in my opinion, highly desirable.
>
> 2) Add language along these lines:
>    -  clients SHOULD accept article numbers up to 2^63-1 (NOT 2^64-1)

I see no particular reason why 2^63-1 is used here rather than
2^64-1. It only lets implementors get away with inconsistent code.

>    -  servers SHOULD NOT generate article numbers over 2^31-1

Maybe. I'll happily ignore it on grounds that I'm not putting up
arbitrary limits if my code does 2^32-1 or 2^64-1 perfectly.

>    -  servers MUST NOT generate article numbers over 2^63-1

Which is nonsense. We may as well allow 2^64-1.

> 3) Keep the 2^32 limit but add an extension for large numbers.

One word: Ugh. Translated: this is bloat for no good reason.

-- 
Matthias Andree