ietf-nntp New wording on article numbers - draft 3

Neil R. Kaethler neilka at ims.microsoft.com
Fri Jan 10 12:37:25 PST 1997


----------
> From: Chris Hall <chris.hall at turnpike.com>
> In article <Pine.NEB.3.95.970110184548.1799t-100000 at apb.iafrica.com>,
> Alan Barrett <apb at iafrica.com> writes
> >"Clive D.W. Feather" <clive at demon.net> said:
> >>     The server MUST ensure that article numbers are issued in order of
> >>     arrival timestamp; that is, later arriving articles MUST have higher
> >>     numbers than earlier arriving ones.
> 
> >This effectively declares that feeds between master and slave news servers
> >(where the slaves want to use the same article numbers as the master) may
> >not use any parallelism.  (If several articles can be transferred in
> >parallel, then I believe that there's no way to guarantee that articles
> >will never arrive at the slave out of order).  I still maintain that
> >prohibiting such parallelism is an undue burden on implementations.
> 
> Let me see if I understand this correctly.  Are you saying that a
> collection of articles numbered, say, {12,13,14,15,16,17} at the master,
> could arrive at the slave in, say, the order {13,15,12,17,14,16} ?  But
> all earlier articles would arrive before this collection, and all later
> would arrive after -- so the out of order arrival is localised ?
> 
> If so, could the slave not avoid exposing the out of order arrival ?
> That is, could the slave avoid serving an article (or its number) until
> all lower numbered articles have turned up ?  (Assuming you can
> guarantee that the articles will turn up, even if you cannot guarantee
> the order.)
> 
> >I could be satisfied if the spec explicitly catered for master/slave
> >configurations by saying that the master must assign article numbers in
> >order of arrival, but the slave may receive articles from the master out
> >of order and clients should be able to cope with that.
> 


Master/Slave servers are also presented as a single DNS entry
by many large NNTP sites.   In this situation it's important that the
slaves do their best to appear identical.  This is done so that the site
can support a very large number of clients with only one internet 'presence'. 
Logic which conceals part of the available article numbers until 
the entire space is contiguous would pose two problems for such a site : 

The Slaves may loose the appearance of being identical for some time 
if the feed from the Master hiccups or attempts to use parallel sessions.

If the Master expires or cancels articles creating holes in the article numbering
scheme there may be no reasonable algorithm a Slave could use to determine
when the extra set of article numbers should be exposed, since the slave may
never receive the required articles to make the article numbers contiguous.

Finally, even if a Slave were to guarantee that its own numbering of articles
was always contiguous, two visits by a single client to a Master/Slave site could
result in connections to different slaves.  This could yield the illusion of 
back-filling even if no individual Slave actually did so.  (This is easiest to 
imagine with a newsgroup with a small number of articles, i.e. 1 article, in which case the
slaves may have entirely disjoint sets of articles numbers.)

I agree that 'back-filling' should be avoided, prohibiting back-filling is 
too much to require for Master/Slave situations.  The RFC should maybe
set the expectations for how often this happens rather than trying to eliminate
by fiat an issue which can be very difficult to avoid in some NNTP deployments.
There are several NNTP sites which operate as I described.

thanks,
Neil Kaethler





More information about the ietf-nntp mailing list