Jump to content

Improved auto-ban system idea (Part 2)!


Lexxington

Recommended Posts

Two ideas:

1. When a piece arrives and passes a hash check, any peers that are suspect that contributed to that piece "redeem" themselves (reduce their fail count by 1). A very simple extension of the existing system.

2. After a peer has been flagged as suspect, attempt to minimise their interactions with other suspects, and their potential impact on other pieces. Basically, as much as possible:

a. A suspect will not participate in a piece that any other suspect is participating in;

b. A suspect will only participate in one piece at a time.

Obviously, this won't always be feasible, so various combinations of suspects and pieces could be used to minimise their interactions.

The second part pretty much needs the first part so suspects can redeem themselves.

I suspect that simply implementing #1 (redeeming) would reduce the number of false positive bans, and potentially allow reducing the number of hashfails required for banning. Implementing #2 would hopefully further improve this (better data going into the hashfail counts).

Link to comment
Share on other sites

Hi magao,

I think those are great ideas. :)

Giving the opportunity for a suspect to redeem his cred' seems a really sensible thing to do.

After all, we want to give everyone a fair chance. If #1 alone was implemented it would almost certainly improve the current situation with the auto-ban enormously.

#2 seems to me to be just common sense. It's daft to throw suspects straight back into a piece with other suspects isn't it?!

This idea also prevents the wasted redundant time spent re-downloading blocks that KS referred to.

#2b is what I suggested as my original idea. I suppose this is the most certain way of eliminating or condemning suspects.

I think implementing #2a in conjunction with #1, by throwing suspects into a piece with other NON suspects will work pretty well anyway because of probability alone and based on the assumption that the majority of people in the swarm are NOT corruptors. Eventually it should lead to the real corruptors getting more +1's and then banned, whilst the innocent suspects tend towards 0 again with -1's.

Pretty neat.

I still haven't been able to verify the blocks theory one way or the other, because all the corruptors in this 7.5 Gb swarm have vanished!

I've been downloading popular TV shows and films from Mininova at random, but absolutely none have them have given any hash-fails.

Pretty frustrating sitting here with the tools to do the job now and nothing to test with! Grrrr... :)

Link to comment
Share on other sites

the only solution without any exceptions should be to permban someone that sends you bad data,

corrupted data that actually makes it out on the internet doesn't happen today, quality of network equipment etc is so good

the only reason you get bad/corrupted data is because someone wilfully and intentionally sends it to you,

and therefore they should be automatically banned without pardon,

introducing some automatically 'forgiving' mechanism that will unban people that spreads bad data will only hurt the bittorrent protocol, and introduce ways for anti-p2p companies to slow down and poison torrents and networks,

the only action is to freeze out the saboteurs, I´m thinking best to do it on the on the peer side and not on the tracker side, but maybe put in some manual unban feature if enough people says its needed

Link to comment
Share on other sites

the only solution without any exceptions should be to permban someone that sends you bad data ...

introducing some automatically 'forgiving' mechanism that will unban people that spreads bad data will only hurt the bittorrent protocol, and introduce ways for anti-p2p companies to slow down and poison torrents and networks.

I agree 100% that anyone who sends bad data should be immediately banned. Now - I have received a piece from 7 different peers. The piece fails its hash check. Who should I ban?

The idea of not banning until a peer has been involved in multiple hash fails is to prevent banning good peers. There are many different algorithms that can be used to decide if a peer is bad. µTorrent uses a simple one - if a peer is involved in 5 pieces that fail a hash check, they're almost certainly a bad peer.

Unfortunately, a good peer could have the bad luck to be involved in 5 pieces that a bad peer is also involved in - and this becomes more likely the more bad peers there are. So on a heavily-poisoned torrent, you're likely to end up banning all the good peers ...

By allowing a peer to redeem themself, it gives an extra chance for them to let you know that they are a good peer. But by itself that won't help much in a heavily-poisoned torrent - hence the need to minimise the interactions between suspected bad peers.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...