Re: [p2pi] FYI - "Inside the Attack that Crippled Revision3"

I think you're right -- MD was tracking those who were exploiting
Revision3's open tracker -- and/or they were putting their own fake torrents
there.

However, the behavior of several torrent clients I've used do not respond
the way that MD did when the tracker throws an error (e.g. "Not
Registered").  They will either to stop the task and wait for the user to
start it again, or, wait for a minimal interval (which doubles on each
attempt) and then ask the tracker again.  This is not by specification, but
by common programming practices with networking applications experiencing an
error.

With the above in mind, if they were tracking a number of different hashes,
most clients I've used would attempt at least once per hash.  The error
response thrown for a single infohash query attempt would not apply to
different infohash queries using the same tracker.  Individual clients don't
do enough simultaneous tasks to matter.  But if MD tracks thousands upon
thousands of hashids on a single tracker, they would be well advised to add
some anti-hammer code to prevent hammering even though the infohashes
differ.

Robb Topolski

On Fri, May 30, 2008 at 3:17 PM, Nicholas Weaver <nweaver@icsi.berkeley.edu>
wrote:

> Actually, it sounds like MD was tracking those who were exploiting
> Revision3's open tracker.
>
> They were set up to agressively monitor, and when they found a hash in the
> open tracker that was being used to host questinable material, they kept on
> it.  And when all those hashes all got removed at the same time, their
> monitor went bonkers as it tried to reconnect to every single hash all at
> once.
>
> At least, thats what I'd be doing.
>
>

-- 
Robb Topolski (robb@funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/