Ban ip when hash fails X times / ratio check

[Switeck]

One way to reduce your chances of YOUR ip being mislabeled as 'bad' is to reduce your upload slots. If you're uploading to fewer people at once, you're uploading faster and are more likely to complete torrent chunks by yourself.

If a torrent has LOTS of peers+seeds, banning 'random' ips because you got a bad chunk it isn't so bad...it's when there's less than 20 total ips on a huge torrent that it's painful.

[z9999]

I already have done that, but primarily because my UL speed isn't very high. It appears that but a few of us encounter bad data making this a very low, actually no priority complaint I'm trying to check out some other client sites to see if perhaps someone is interested in improving the way bad data is handled in relation to banning peers. It bothers me because it seems that most often it is the peers who UL the most data to me that are quickly banned dropping my speed drastically. Well, I gave it a shot here and I'll remain subscribed in case something new happens, but it appears no action is deemed necessary.

Just a little info to chew on:

As many pieces become queued, 50-60 or more, and peers often send but a small amount of a piece, sometimes just 1 block, a peer who is giving bad data can set up many if not all those pieces for eventual hash fails to occur long after being banned for accumulating involvement in just 5 of them. By the way Azureus allows you to see the IP of each peer who contributed to a piece and the block numbers he/she contributed. You can, with much effort make a reasonable determination of who actually was responsible for many of the hash errors, make note of all the banned IPs, restore them and manually ban the one(s) you feel are responsible. It's a real pain, but when the piece sizes are 4mB, and there are more than 50 queued, it sometimes can eliminate many hours of seeing hash fails when the peer who caused them had long ago been banned along with numerous others, and continues to cause others to be banned erronously. I've had to watch several hundred mB's of bad data occur several times. And last of all, it often isn't a malicious act of the peer responsible for the hash fails, as the data may have been fine leaving but somehow got mangled in transit. I have seen peers who quickly get banned when they are restored, but several days later the data they send is error free. I've been watching this closely for a couple of months now making notes and trying different things to reduce the wasted DL's, and just wish it could be done without paper and pencil so I wouldn't have to sit and watch continuously.

Good luck.

[Switeck]

I have to make use of a very long ipfilter.dat to avoid the numerous intentional posioners of torrents.

However it would be nice if there were a stronger criteria for banning ips than simply hash fails X times.

A 4 GB torrent running possibly for weeks might see ips that very rarely send bad data getting banned just due to the time involved...without any of them sending more than 1 bad piece per 10,000+.

[z9999]

I agree with you, and only wish to state that there are numerous reasons, in addition to intentional poisoners, as unintentional errors also occur and create the same results. It would be nice if some effort was put into correctly identifying the source of the bad data without banning others along with or instead of the source. For me, I would like to be able to selectively unban peers who had been big uploaders that erronously get banned. I still feel the large number of pieces queued only makes the problem worse and would really like to have a way to limit it, when I feel it is necessary. In other words a large file which usually has pieces of 4 mB size that appears to be accumulating a large number of hash errors could have it's queue reduced temporarily which would deny an intentional poisoner from contaminating many pieces by just sending 1 bad block to each, and then would be banned more quickly without involving many others, and also not leaving behind many pieces which will later fail that were contaminated prior to being banned. I just wish there was an effort to try and reduce the problem as it appears from reading various forums that more than just you and I feel this is a problem. I'm still looking for a forum where there is interest in finding a solution. If it means changing clients again, that's ok too. I liked some of the features in Azureus, but it is a memory hog, and appears to accumulate handles. I've also tried Bit Comet and have it appears no matter which client you run the problems remain the same. If I find anything more positive to report I'll post it here also. As I mentioned previously, Azureus provides more information which enables you to make an educated guess as to who should and who shouldn't be banned and allows you to manually ban a peer to see if it is the one sending bad data. The only problem is you have to re-enable all banned peers and keep an active list of those who should remain banned. Oh, and another problem in resolving this is dynamic IP addresses which change frequently, but you can often tell who they are if you keep written records of who has what percentage, and watch the country flags too. I'm beginning to believe Bit Torrent is not something you just start running and leave alone, and I have to sit for hours trying to figure a way to improve the efficiency. If you learn anything new please post it and I'll do the same.