Not really a bug... but thought I should let you know.

[dodecahedron]

Interesting issue that came up.

Situation:

User A and User B both share the same 1gbit seedbox.

User A and User B are running the same torrent from the same site.

User A is using Utor 1.8.4. User B is using Utor 1.7.7

Normally they will share data with each other like normal, however at a much faster rate.

Issue:

After a reboot and updating Utorrent from 1.8.3 to 1.8.4 user A reloads all his torrents back into his client. For some reason a previously incomplete torrent hash checks to 100% and reports to the tracker that he's now a seeder. The tracker now passes that information along to the swarm.

Obviously User A doesnt have the rest of the data, but his client thinks he does. So he sends out bad data that creates hash errors and thus gets his IP banned in the swarm.

Ok thats not the problem. The problem is that User B and User A are using the same IP. Utorrent cant ban its on IP. So what happened is that User A sent bad data to User B. User B's client checked it and it failed, and rerequested it. Since utorrent cant ban its own IP, User B's client is unable to ban the IP of the seeder sending faulty data.

This problem is compounded by the fact that since they are sitting on the same seedbox, the data transfer is sky high. So in a matter of minutes GB's of bad data has been sent from User A to User B.

This obviously stuck out like a sore thumb when I saw my data transfer rate on a torrent that was 10GB and I was transfering at 50+MB/s to a peer, and seeding over 40GB worth of data transfer to that peer (on a 10gb torrent). Thankfully I noticed this quickly and the client didnt run for hours trying to do this, or the amount would have been attrocious.

The Admin of the tracker and I are friends so I spoke with him, explained the situation and we worked it out.

Its important to note that User B's client did not report downloading 40GB worth of bad data becuase if failed hash check.

Utorrent wont report failed hash data to the tracker.

However User A's client not knowing it was bad hash data did report the upload So from the trackers point of view, User A is reporting WAY more traffic that is possible (since no one else is reporting that amount of download)

We were able to calculate out the amount of faulty upload credit my client reported to the tracker, and adjust my stats to match. But this issue would not have happened if not for the fact that User A and User B share the same seedbox (thus introducing the inablility for Utor to ban its own IP).

So its not really a bug... per say. But It was odd enough that I felt like I should pass it along to you guys in case you'd want to know about it. I doubt that this issue will arrise often, but when creating big torrents (and some people's tendency to skip hash check when starting them) it may be an issue that creeps up from time to time.

Cheers.