According to Media Defender, they were monitoring 260K torrents in Revision3's open Tracker, which Revision3 has said could well be true. Revision3's claim is that their Tracker was open from when they launched until a year ago, then was closed, then when it started crashing they opened it again (5 weeks ago), and was closed last weekend. Revision3's theory is that torrents are packaged with a long list of trackers, including theirs (because it was open a year ago), so when it was reopened the torrents all announced to them, instantly making them a very popular pirate Tracker. I don't see a lot of multi-tracker torrents, much less torrents with trackers that have been down for a year, but it's possible...
The alternative is that in five weeks 260K new torrents were packaged with their newly open Tracker, which would be stunning.
In either case, tracking 260K pirate torrents would have generated tons of traffic that Revision3 should have noticed, since it would dwarf whatever level of traffic they saw on their (hundreds?) videos that they were delivering using BitTorrent.
Two things that's not clear to me from the coverage - perhaps someone else here knows more:
1) Did Revision3 really see a SYN flood attack, or were they just getting so many TCP connection attempts (from broken retry logic) that they couldn't handle it?
2) Was MediaDefender using Revision3's open tracker to host their own torrents (which is what Revision3 claimed) or were they running BitTorrent clients that joined pirate torrents running on Revision3's open tracker?
- Laird Popkin, CTO, Pando Networks
mobile: 646/465-0570
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 at 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 at funchords.com)
Hillsboro, Oregon USA
http://www.funchords.com/
_______________________________________________
p2pi mailing list
p2pi at ietf.org
https://www.ietf.org/mailman/listinfo/p2pi
