RapidAntiSpam

MeatballWiki | RecentChanges | Random Page | Indices | Categories

In an anti-spam network like SharedAntiSpam or PeerToPeerBanList, new patterns need to be spread throughout the network at a rapid pace to prevent spammers from creating too much havoc. Yet the usual method of spreading patterns — polling — has an inverse proportionality between this update latency and the wasted overhead of polling when no updates are present, either placing a huge burden on the servers of anyone wishing to publish a blacklist, or allowing large delays between update and global immunization.

The network structure does nothing to alleviate this problem. In a SharedAntiSpam system with a global server, latency is low because updates do not need to propagate far, but as the network grows, the cost to the blacklist provider grows untenable. In a P2P system, the network traffic at any given node can be kept low, but the latency of global immunization now grows as the network does. Any steps taken to prevent node downtime breaking the network will only increase the problem.

Therefore, use Rest:HttpEvents instead of polling. Each publisher in the system maintains a list of subscribers, and actively pushes new updates to them all via HTTP. Subscribing to a publisher is quick and easy, a single HTTP request. Now latency is kept minimal, yet the network traffic generated is a simple function of updates times subscriptions. Further, the bandwidth used by the system can be actively controlled by the server. The approach even supports decentralization of a publisher's burden, transparent to the subscribers, allowing a simple SharedAntiSpam system to work even if the number of subscribers grows beyond the capacity of the original server.

An OpenSource library for setting up or joining a RapidAntiSpam network can be found at [SourceForge:http-events], and [our own list of spam patterns] doubles as a publisher. Currently an early beta, comments, bug reports and even source code are all welcomed. Let's make anti-spam a reality!

The http-events library has a lot more potential than anti-spam, particularly with the coming explosion of RSS through Longhorn/WSS. It's essentially an Observer-notify pattern (push rather than poll), which is the right way to do things.

: The disadvantage is that the subscriber has to act as a web server to accept Rest:HttpEvents - not something that's likely to be allowed in browsers any time soon, nor let through corporate or even personal firewalls. Right now, Rest:HttpEvents is useful for keeping servers synchronized. -- ChrisPurcell

CategorySpam

RapidAntiSpam

Discussion