PEX or DHT sort of thing for banned peers UPDATE

[Ezra]

Some time ago I posted an idea about collective blocking.

There were some problems that peers could be blocked because of defective routers. Now I thought of a different idea to counteract that. When 5 hashfails occur the peer will be flagged in the system and when 5 different peers flag the same peer it will be blocked. This way the same peer has to have 25 hashfails spread over 5 peers (maybe more), to be blocked. And after a timeout of like 24 hours the peer will be released from the system.

The amount of hashfails and flags are just as an example, but seem very reasonable to me.

What do you think of it?

[Firon]

And it can still be abused by just faking it. Very easily. Still equally flawed. Nevermind the fact that with D-Link Download Destroyer™ (and D-Link routers are common), you'd end up banning legit peers anyway.

Maybe the third time's the charm?

[kewldude607]

I don't like it. 5 pieces isn't that much anyway.

[Ultima]

Heh with the number of people using D-Link, you'd probably end up with at least 5 people on a large swarm who ban a peer because the peer sent them "bad" pieces 5 times. And that's just one way that peers can have their pieces corrupted. There isn't a perfect way to do this, and it'll end up hurting the swarm if legitimate peers get banned, and they almost certainly will. Basically, these suggestions, though made with good intentions, won't work well when other variables are taken into consideration.

[Klaus_1250]

Gnutella implemented a similiar feature quite a while ago, but how has that been working? I like the idea behind the feature, but I think it will fail or do more harm when implemented (as Ultima points out). The only way you could implement it is if you don't block peers, but block specific pieces / blocks from peers AND if the block is implemented as an advice rather a real block. (more in the line of: try to avoid downloading this specific piece of data from this specific peer).

At the same time, it should be implemented the other way around too. If a hash fail occurs, the sending peer of the data should be notified of that. That way, the peer could avoid sending certain pieces of data (for which it knows hash fails will occur) and/or notify the local user.

[bleh]

The problem with this system as others have pointed out, is that it's susceptible to fake packet generation, something certain organisations (you all know WHICH .. right?) have been prone to do in the past. Imagine this organisation , putting on 30, no.. 300 peers which all fake broadcast messages to peers that everyone in the list is a "bad peer" and should be blocked.

Imagine the chaos.

I do like your trail of thought though, because I also feel that fake sharers (which are of the above mentioned organisations) that only send corrupted pieces needs to get their ass handed to them collectivly.

[Ezra]

You are all right, didn't think about faking the packets, damn I thought I had a good idea ...

Well I hope I atleast have got some people thinking about getting back at those fake sharers.

I'll sure keep on thinking of new ways to get them blocked