[NNTP] Notes on auxiliary documents

Andrew - Supernews andrew at supernews.net
Thu Nov 11 04:13:32 PST 2004


>>>>> "Clive" == Clive D W Feather <clive at demon.net> writes:

 Clive> streaming-02
 Clive> ============

 Clive> I notice that you switch between "pipeline", "stream", and
 Clive> "asynchronous transfer" with no apparent consistency. We
 Clive> agreed to call the basic concept "pipelining", and that's what
 Clive> the core document calls it. You may want to revisit this.

The term for article transfer using check/takethis is "streaming feed"
(and has been since the concept was invented). The fact that the main
document uses "pipelining" to refer to sending multiple commands before
receiving responses isn't relevent to that (and in fact the main doc
deliberately doesn't use the term "streaming" for that precisely because
that term has always had the specific meaning of "streaming feed").

 Clive> Section 2.4.2: is "another client is sending the same article"
 Clive> the best example? Surely "disc full" or something like that
 Clive> would be better.

You really don't understand how streaming feeds work at all, do you?

"Another client is sending the same article" is the SOLE REASON WHY THE
DEFERRAL RESPONSE CODE FOR "CHECK" EXISTS. The normal case is that the
server receives CHECK commands for a given article from several peers
more or less simultaneously; it answers the first one with 238 and all
the rest with 431, until either it receives the article via TAKETHIS or
a timeout expires (in which case it answers the next CHECK for that
article with 238 again). This is necessary to avoid wasting bandwidth
by getting multiple copies of the same article.

The usual (and most reliable) way to handle "disc full" is to throttle
the server, i.e.  to stop accepting feeder connections at all.

-- 
Andrew, Supernews
http://www.supernews.com




More information about the ietf-nntp mailing list