Cancel distribution network ideas

Marco d'Itri md at
Sun Apr 16 19:14:08 UTC 2000

On Apr 15, Olaf Titz <olaf at> wrote:

 >This is basically like NoCeM with all the formatting removed, and
 >without indication of the target newsgroups. (Should we keep the
 >target newsgroups?
Yes, because sites which don't get a full feed want cancels, but
will not want to waste bandwidth for cancels in groups they don't carry.

 >- Receive messages on a UDP port,
 >- Accept connections from configured peers on a TCP port,
What about UUCP systems?

 >Message loop detection:
 >- Each message contains a hop counter which is incremented on the way.
 >  When it reaches a configured maximum, the message is discarded.
 >- Messages carry a timestamp, they are discarded when too old.
This is very ugly because a lot of cancels will be sent more than one
time to the same peer. You are stripping a lot to reduce size, but you
have not showed why you think current cancels are too big.

 >- It can be assumed that one issuer does not issue more than one
 >  message with the same timestamp (i.e. more than one per second).
You can't assume this! Most cancelbots generates more than one cancel
per second.

Why reinventing the wheel? I think cancels should be carried with the
same protocol of normal articles, because that will solve all problems
except authentication. I think we should consider developing (another)
extension for authenticating traditional cancels or maybe a new kind of
control message.


More information about the inn-workers mailing list