Proposed patch: cancel channel

Russ Allbery rra at stanford.edu
Sun May 14 02:14:24 UTC 2000


Olaf Titz <olaf at bigred.inka.de> writes:

> That said, I'm still not sure if the cancel channel protocol is designed
> right, and this is the reason I didn't push it more. :-) The current
> application does not need responses at all - for NoCeM, and for the
> proposed cancel-distribution network, it doesn't matter if a cancel was
> sucessful, proactive, lost, or failed. (Other than for statistics.)
> Especially with regard to the I/O loop and buffering concerns it would
> be nice if the client would just send cancels and never look for a
> response. (My current client doesn't do that; it could just throw the
> responses away instead of waiting for them.)

> So there is the question: do we need the responses or would it be better
> to just skip them? The code change in innd would be trivial of course.

I guess it largely depends on how important keeping statistics are.  I'd
actually be interested in having statistics for which cancels got an
article already on spool and which ones just resulted in an entry in
history.  The current responses don't give that information, but if
responses are part of the protocol that gives some place to convey that
information.

You could also build a network of cancel servers using the same protocol,
in which case again responses would be useful for statistical purposes.

-- 
Russ Allbery (rra at stanford.edu)             <http://www.eyrie.org/~eagle/>



More information about the inn-workers mailing list