ninpaths updated

Olaf Titz olaf at
Wed Jan 17 10:26:49 UTC 2001

> Is there a description of the MODE CANCEL stuff somewhere?

Nothing more than the description of the original patch:

< Purpose: Add a command for efficient application of large numbers of
< local cancels.
< Reasoning: Programs like NoCeM clients need a way to cancel many
< articles. Spawning "ctlinnd cancel" or using the datagram command
< socket is too inefficient (because every single cancel needs to
< establish a new socket, deal with timeouts, etc.) What is needed is a
< way to send cancel commands through something like an NNTP socket.
< Description: This patch adds a new NNTP commmand "MODE CANCEL". That
< command can only be used from the local Unix domain socket. It answers
< 284. Every following command line should consist of a single
< Message-ID. The message gets cancelled, and the server replies 289 for
< success and 484 for failure. (Failure can occur e.g. when the server
< is paused.)

There are only two important points: use the AF_UNIX socket, and the
284 reply code. You can ignore the other replies or use them for
statistics, they are not relevant to the operation (in particular, you
don't have to wait for them).

> - what if perl-nocem backlogs a bit (the socketpair() between
>   innd and perl-nocem can buffer up to 32k), and innd gets
>   paused or throttled
> - nothing in perl-nocem processes the spool files ever.

(I think) I solved both of these in c-nocem by doing internal
buffering backed up by spool files, a la innfeed. The key is reading
any line of input into an internal queue as soon as it shows up, and
processing this queue as needed - anything which remains in the pipe
buffers between innd and the consumer is prone to lossage. innd's
spool file mechanism won't help in this case.

This is a common problem with all channel feeds. It mostly shows up
only when the consumer is slow[1], but there is no completely
race-free solution AFAICT. (Apart from using an IPC mechanism which
does no in-kernel buffering or only atomic message buffering.)


[1] or when either of the processes gets SIGKILLd, but you don't do
that anyway ;-)

More information about the inn-workers mailing list