[NNTP] Notes on auxiliary documents

[Andrew - Supernews]

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

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

 Clive> Okay. But in which case "has offered to send the same article"
 Clive> would be better wording.

Yeah.

 Clive> As phrased, it looked like "another client has already started
 Clive> an IHAVE or TAKETHIS for the article, but it hasn't completed"
 Clive> and seemed an odd reason for giving a defer code (if it fails,
 Clive> that other client can re-send).

That case applies as well. The article can't be considered "received"
until the IHAVE or TAKETHIS is completed; and during the interval
between first seeing the message-id (whether by CHECK, IHAVE or
TAKETHIS) and the completion of the IHAVE or TAKETHIS, the server will
(generally speaking) return deferrals rather than refusals simply
because it has no way to ensure that a failed in-progress transfer
will ever be retried by the sending end.

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

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

It makes sense in the context of the normal case described above. But
it's _not_ OK to simply respond to _every_ CHECK or IHAVE with a
defer, because that means that both ends of the peering session will
just waste bandwidth and CPU on a continuous stream of deferrals.

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