431 for TAKETHIS

Don Lewis Don.Lewis at tsc.tdk.com
Fri Sep 17 14:38:42 UTC 1999

On Sep 17,  6:36am, Russ Allbery wrote:
} Subject: Re: 431 for TAKETHIS
} Don Lewis <Don.Lewis at tsc.tdk.com> writes:
} > What if feed-A is running in no-CHECK mode because everything it has
} > been sending has been accepted the following sequence of NNTP commands
} > happens?
} > 	feed-B sends "CHECK <message-ID-X>"
} > 	response "238 <message-ID-X>"
} > 	feed-A sends "TAKETHIS <message-ID-X>"
} You accept the copy from feed A and reject the article that feed B sends
} you as a duplicate.  Or vice versa.
} Why would you respond to receiving a complete copy of an article with a
} response code telling them to send it to you again?  Either accept it or
} reject it; it's not going to look any different the second time you get
} it.

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.

You could also do an early deferral to abort the reception of the
second copy of an article and wait for the complete reception of
the first copy.  Even if the response is too late to keep the second
copy of the article from being sent, the only cost is an extra CHECK
which would then be refused.

I agree that it doesn't make sense to send a 431 if you've received the
whole article.

More information about the inn-bugs mailing list