431 for TAKETHIS
Don.Lewis at tsc.tdk.com
Fri Sep 17 13:16:44 UTC 1999
On Sep 17, 5:07am, Russ Allbery wrote:
} Subject: Re: 431 for TAKETHIS
} Fabien Tassin <fta at oleane.net> writes:
} > It's not the goal of TAKETHIS to deal with retries. If you really want a
} > try-again-later the best way to do it is to use CHECK or IHAVE methods.
} This is largely due to the problem that "try again later" was designed to
} handle. If you have multiple peers offering you articles at the same time
} with CHECK, you may get an article offered from both peers at once. If
} you just accept from one peer and refuse from the other, and the first
} peer never sends you the article, you may never get the article at all.
} So you send "go ahead" to one peer and send a deferral to the other.
} If you've just received the entire article with TAKETHIS, there's no
} reason to do that; just accept and store the article that you just got and
} reject/refuse additional copies.
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
feed-B sends "CHECK <message-ID-X>"
response "238 <message-ID-X>"
feed-A sends "TAKETHIS <message-ID-X>"
Judging by the comment in innfeed
case 431: /* try again later (also for TAKETHIS) */
I think that this is supposed to work.
More information about the inn-bugs