This is a discussion on Re: Rulesemporium - SpamAssassin ; On Thu, 12 Jul 2007, Kelson wrote: > I don't think the typical SA ruleset is big enough to take advantage of > BitTorrent. Too much overhead. For comparison, Firefox updates are typically > several hundred kilobytes (on Windows & ...
On Thu, 12 Jul 2007, Kelson wrote:
> I don't think the typical SA ruleset is big enough to take advantage of
> BitTorrent. Too much overhead. For comparison, Firefox updates are typically
> several hundred kilobytes (on Windows & Linux, anyway), and they've looked
> into torrents and concluded they wouldn't gain anything by using them.
However, what you might gain is the redundancy if (in fantasy world) every
user was also serving them out via bittorrent.
I was just mulling over in my head a hypothetical "BittorrentMirror" client.
The idea being to mirror a group of files (rulesemporium rules, the whole
You start as a standard torrent, retrieve all files, and stay on the torrent
When an update is available a new torrent is made. Clients can either check
periodicaly for new versions of the torrent (DNS TXT record as clam uses) or
just watch for the old tracker shutting down). At that point they grab the
new torrent file, dissconnect from the old and reconnect to the new.
As long as the actual directory the torrent's files are in doesn't change,
it should only start transfering changed files -- and only the parts that
changed, effectively using the torrent chunk checksums for rsync
Once the torrent is back up to date, you need a signal to trigger that these
rules should also be made 'live' (used by SpamAssassin). The only other
'addition' to standard bittorrent clients would be a way to remove files no
longer in the mirror, if wanted. Other than these two things you could
probably do this with standard clients and some scripting.
And someone to make the torrents.
Chris Candreva -- firstname.lastname@example.org -- (914) 948-3162
WestNet Internet Services of Westchester