Re: ietf-nntp Backfill

[USENET news manager <[e-mail]>]

>Jon Ribbens <[e-mail]> writes
>>I am looking at INN 1.4 for this reply.
>
>>> [Q2] When will new articles become available and expired/cancelled ones
>>> become unavailable ? Is it:
>>New ones will become available and deleted ones will become unavailable
>>immediately. However 'NEXT' will not attempt to show deleted articles,
>>and it will not attempt to show newly-arrived articles. This seems
>>reasonable to me.
>
>So you are saying that NEXT from article 1200 might give article 1234,
>even though there is an article 1212 ?
>
>Hmm. I would never have thought of that as being a behaviour permitted
>by RFC 977. But I can see where it comes from.

Read it in the context of the following point! An article 1212 should not 
appear "from nowhere" if the high article number is already greater (e.g. 
1234).

>>> [Q5] Can an article appear with a number between the previous limits,
>>> such as 1250 ?
>>No.

Given that under normal circumstances (see below for the one exception I've 
encountered), article numbers within a group are monotonically increasing,
there should never be a newly-arrived article within the min-max bounds
determined earlier. NEXT should simply find successive articles that have
not expired or been cancelled (and may have large gaps to skip if there are
long-lived articles due to Expires: headers).

On a related point which I saw queried in an earlier message - if the highest 
numbered article is cancelled (or a number of articles at the end of the 
range), INN's implementation of the GROUP command will return the actual
low/high article numbers to the client *but* the high article number in the
active file (also available to the client, of course) will never decrease
and newly-arrived articles will be assigned numbers continuing on
from the highest used so far. The high numbers will not be reused simply
because articles have been cancelled, though they may not be mentioned as 
part of the currently-available range.

>Someone said at the BOF that this *does* happen with INN.

It could happen, but only in limited situations which would count as misuse
of the tools rather than working as intended.

I'm thinking of a situation such as an INN slave-mode feed (i.e. where the 
sending server specifies the article numbers to be used, to yield an 
identically-numbered spool on the slave) where for some reason batches of
articles were not sent across to the slave server in arrival order. 

I've tripped over that when using slave mode to copy over articles from
long-expiry groups while setting up a new server, with batch files
constructed by non-standard means (the old server was running C-news :-),
*but* the server didn't go live until later when it was running "normally"
with articles arriving in order (albeit still in slave mode, for a 
transitional period), and I considered it a trap to avoid during live
running, not something which client software ought to handle. Slave mode
would normally send articles in arrival order and hence, as usual, the
article numbers within a group would be monotonically increasing even though 
specified by the sending server.

[The problem that I actually encountered, and which drew my attention to the
issue, was that INN's overview data entries were written in article arrival
order even though that did not correspond to article number order within the
group because the sending server specified the numbering based on its spool.
In consequence, INN ignored the overview data and performance was poor
until I deleted and recreated the overview files.]

                                John Line
-- 
Cambridge University Computing Service - USENET news manager. Usually John Line
[e-mail]    (alias {newsmaster,news,usenet}@news.cam.ac.uk)