From Newsgroup: news.software.nntp

Hi Chris,

What I'm particularly interested in is backpressure caused by the receiver's internal queues.

For example, suppose a TAKETHIS receiver has accepted an article, but its internal ingestion queue has reached its configured memory limits. With IHAVE, we can use 436 to tell the sender to try again later. TAKETHIS doesn't appear to provide an equivalent per-article temporary response.

This temporary response is provided by the CHECK command:
431 message-id Transfer not possible; try again later

- Is 400 + connection close intended to be the mechanism for this kind of temporary receiver-side overload/backpressure in TAKETHIS?

You're supposed to send a CHECK command before actually sending the
article. Indeed, the remote peer may already have received the article
from another feed, so no need to send it again!

- If so, what should happen to TAKETHIS articles which have already been received but have not yet received a 239?

"""
The client SHOULD NOT assume that the article has been successfully
transferred unless it receives an affirmative response from the
server. A lack of response (such as a dropped network connection or
a network timeout) or a 400 response SHOULD be treated as a temporary
failure and cause the transfer to be tried again later if possible.
"""

- Does the sender treat the articles which have no 239 as retryable after
the connection is closed?

Yes.

- Is there an established interpretation in INN, Diablo, or other major implementations for this situation?

The above behaviour is stated in Section 2.5.2 of RFC 4644.
innfeed implements it, and I bet Diablo too.

- Is there any recommended threshold/timeout/window behaviour before a receiver resorts to 400 and closing the connection?

It is implementation-specific.
FWIW, you're supposed to send pipelined CHECK commands before TAKETHIS.
By default, innfeed sends a maximum of 20 CHECK commands (max-queue-size parameter) and won't go on trying to send more articles before they have
been treated. (There is also an optimization with
no-check-low/no-check-high which permit direct TAKETHIS commands under
some circumstances.)

If you encounter a problem in treating too many articles, then just send
431 responses to CHECK, or 400 to TAKETHIS. Also, you can delay the
responses to CHECK and TAKETHIS to make the exchanges slower.

I'm deliberately trying to avoid inventing behaviour here, particularly because sending 239 for an article that we have actually dropped would obviously be incorrect, while 439 would imply a permanent rejection.

You may also send a 403 response code (generic from RFC 3977) though
innfeed currently does not. It does not imply a connection closure. It
is something we may have a look at when we implement new commands from
RFC 3977 in innfeed.

Any guidance on the intended semantics, or pointers to relevant implementation/documentation, would be greatly appreciated.

I hope this message will be helpful.
--
Julien |eLIE

-2-aLe v|-ritable voyage de d|-couverte ne consiste pas |a chercher de
nouveaux paysages, mais |a avoir de nouveaux yeux.-a-+ (Marcel Proust)

--- Synchronet 3.22a-Linux NewsLink 1.2