[NNTP] 32 bit article counters

[Steve Walker]

Russ Allbery wrote:
> Steve Walker <nntp at nntpserver.com> writes:
> 
> Well, no, changing two lines of text does not fix the problem.  Your
> argument is rather that changing two lines of text will get software
> authors to fix the problem in all of their code so that 64-bit article
> counters will then be usable.

What about all the modern code that is already using 64 bit 
numbers?  We had a standard that said no limit.  Some used 32 and 
some used 64bit numbers.  The 64bit people are closer to the no 
limit and are not likely to ever have an overflow problem.  I 
know my code is 64 bit and at least one commercial client author 
I spoke with said they as as well.  I think more modern software 
is 64 bit clean than you think.

> Standards text has no magical effect on running software.  It's possible

What we have now is that some clients do one thing and some do 
something else.  This is exactly what a standard should solve. 
If we change the standard now the effects will not be noticed for 
years.  The servers are going to push numbers past 2^32-1 at some 
point.  They clients authors need to be warned (in the standard) 
and prepare for the time.

> people to miss.  If we say that article counters are 64-bit, but in
> practice nearly all clients are 32-bit, we're not actually doing anyone
> any favors; if that is the case, anyone implementing 64-bit article
> counters following our standard will encounter significant breakage as
> soon as they exercise that facility without any warning at all from the
> standard.

But you can't have it both ways.  You can't say in the standard 
that numbers MUST not roll over and also place a 32 bit limit on 
the number of articles knowing that it's just a time bomb waiting 
to happen.  There are but three logical choices:

1. Use a 64 bit limit.
2. Use a 32 bit limit but allow counters to roll over
3. Don't change RFC977 and use no limit.

The current text says:

The server MUST ensure that article numbers are issued in order
of arrival timestamp; that is, articles arriving later MUST have
higher numbers than those that arrive earlier.

> The purpose of standards is to get people to do the right thing, yes, but
> it's also to ensure interoperability.

It's a fact that the servers will need to exceed 2^32-1 at some 
point.  These clients are doomed to fail if they are not updated 
regardless.  At least we can get everyone to do the same thing.

> Out of curiosity, and to be sure I wasn't overestimating the problem, I
> checked slrn, a widely used Unix news reader for which it was easy to find
> the source.  Here is the function that implements GROUP:

In all reality, slrn users are reading text groups.  They will be 
the last group of users to be effected by a 32bit limit.  I'm 
sure someone can bother to do a s/int/long long/ and recompile.

What you are proposing is changing the standard (RFC977) to place 
a new limit so a few easily changed open source clients don't 
have to be updated, even if it means breaking other clients  and 
servers in ways that can not be fixed.

> portable sscanf directive for reading a 64-bit article number that works
> on all of the platforms to which slrn has been ported.  This code would

Who doesn't have access to the GNU glibc?

s/sscanf(s->rspbuf + 4, "%d %d %d", &estim, &min, &max)/
  /sscanf(s->rspbuf + 4, "%lld %lld %lld", &estim, &min, &max)/

That's not very hard.  And it's hardly an argument to cripple a 
standard.

> I would expect to see similar things in most widely used news readers.

Do you mean to say, most widely used text/unix readers.  What 
about the 100+ million Windows/binary client users that already 
support 64 bit numbers and are not likely to downgrade to 32 bit 
just because the standard changed on them?

Steve.