[NNTP] Large article numbers extension

Clive D.W. Feather clive at demon.net
Wed Jul 27 06:02:42 PDT 2005


Charles Lindsey said:
>> So now we're down to one basic situation: how to report a group with large
>> article numbers in GROUP, LISTGROUP, LIST ACTIVE, and NEWGROUPS. Here is
>> what I would propose:
> 
>> * If the client has not used the BIGNUM command, the server acts as if
>>   the high water mark is 4294967295, except that NEXT fails with 401 BIGNUM
>>   instead of 421 ("no next article").

> The chief problem is that the old client will *never* be able to read the
> recent articles in the overflowed group. That is not good.

I agree. It isn't.

> How does that compare with the alternatives?
> 
> 1. Wrap-around.
> 
> The client would get mightily confused. But, after a while, all the
> articles prior to the wrap would have expired, as which point we are back
> to the present situation. At that point, the client would be able to read
> the group normally.

Not so. If the client is tracking articles by number, it will see the new
articles as if they were reincarnations of old articles. If the new ones
have numbers less than the low water mark for the group, it's likely to
ignore them completely.

Consider a client using a .newsrc file which contains lists of "read"
articles, and assume that the client uses the LWM to prevent the list
growing unboundedly with never-to-appear articles.

> 2. Have a flag day.
> 
> Has anyone actually looked into how a flag day would be organized?

I believe we discussed it here briefly.

> Presumably the server goes off line for a few hours while it renumbers all
> the articles in the affected group, starting from 1 (or perhaps from
> some large constant).

Or by subtracting a large constant from the numbers.

It need not be "a few hours". For example, a traditional Unix spool could
build a shadow directory with the new numbers in, then the transition just
requires two directory renames.

> What does the client see when it comes back? Presumably its .newsrc file
> is all wrong.

Indeed.

> Somehow it has to reset that line of its .newsrc file,

This may be a software option if it isn't a text editing job.

> at
> which point it will be offered all the already-read articles in the group
> as it they were new. Tedious, but manageable, and no articles are lost.

The same is true with wraparound.

> And with a bit of assistance from the server (for example, a list mapping
> old numbers to new ones, or making the new numbers differ by a large
> constant from the old ones, or keeping the old group around in a renamed
> form, with Xref headers of old articles pointing to both groups) things
> could be made almost tolerable.

Also true with wrap-around. Indeed, it's probably easier, because you just
mark the low half of the number space as unread.

However, in either situation, what if there isn't a .newsrc file you can
edit? This appears to be the situation in Turnpike, for example. [I
normally use it in Newnews mode, so I'm not completely familiar with this
case.]

What it comes to is that, in both cases, clients need to do something
special to recover from the overflow situation. If this is going to be
coded in, it might as well be done properly so as to eliminate the issue.

If we're going to have a BIGNUM extension, I don't see the benefit in
getting too fancy with those clients that don't implement it. Note that the
above wording does not prevent the server having a flag day if too many
customers complain.

-- 
Clive D.W. Feather  | Work:  <clive at demon.net>   | Tel:    +44 20 8495 6138
Internet Expert     | Home:  <clive at davros.org>  | Fax:    +44 870 051 9937
Demon Internet      | WWW: http://www.davros.org | Mobile: +44 7973 377646
Thus plc            |                            |



More information about the ietf-nntp mailing list