431 for TAKETHIS
rra at stanford.edu
Fri Sep 17 14:44:26 UTC 1999
Don Lewis <Don.Lewis at tsc.tdk.com> writes:
> Innfeed doesn't implement this, but if it got an rejection or deferral
> response to a TAKETHIS, it could abort the article transmission. Doing
> this in the rejection case can save quite a bit of bandwidth in the case
> of large articles if the receiver scans the headers for whatever it
> doesn't want to receive as the article is being received.
True, but I believe it would be a violation of the NNTP protocol to do so
(insofar as streaming is even part of the NNTP protocol, which I realize
is rather iffy). The problem with aborting the transfer of an article is
that you've now sent, claiming to be a copy of the article with message ID
<blah>, an article which isn't actually all of <blah>. This to me seems
dangerously likely to cause a truncated version of the article to get
propagated in the case of some obscure bugs or error conditions.
Premature abort on TAKETHIS or IHAVE would be nice, but I think it would
be tricky to implement and document in a way not prone to that problem.
That's a bit of a different problem than deferral, though. For the
deferral case, I think it's wasted effort for a case that's likely to
happen only with a small handful of articles, because it only is an issue
in the case where you have a peer who's gone into no-CHECK mode, and if
you're accepting enough to put a peer in no-CHECK mode, you've almost
certainly not got other peers sending you any sizeable percentage of
articles at nearly the same time.
Russ Allbery (rra at stanford.edu) <URL:http://www.eyrie.org/~eagle/>
More information about the inn-bugs