[NNTP] Notes on auxiliary documents

Clive D.W. Feather clive at demon.net
Thu Nov 11 04:23:21 PST 2004


Andrew - Supernews said:
>  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").

Okay. In which case, we should be careful that each use of those two terms
is correct, and that "asynchronous" is removed completely.

>  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?

No. That's why I asked the question.

> "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

Okay. But in which case "has offered to send the same article" would be
better wording. As phrased, it looked like "another client has already
started an IHAVE or TAKETHIS for the article, but it hasn't completed"
and seemed an odd reason for giving a defer code (if it fails, that other
client can re-send).

> (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.

Understood.

Note: this may be obvious to you who does this every day, but the spec
should attempt to minimize the specialist knowledge required.

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

Um, I thought you said that deferring made sense after CHECK and the first
stage of IHAVE; it was only after TAKETHIS (and the second stage of IHAVE)
that it didn't.

-- 
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