Opened 15 years ago

Closed 14 years ago

#263 closed Enhancement (fixed)

Reporting hash failed pieces to tracker

Reported by: Dragon Owned by: somebody
Priority: Normal Milestone: 0.90
Component: libtransmission Version: 0.80
Severity: Normal Keywords:


Both Azureus and uTorrent in current versions do not report discarded data resulting from hash failed pieces to the tracker, this behaviour seems to be be beneficial to the user in avoiding bad ratio on any sites that actively monitor ratio and thus would be beneficial to be implemented in Transmission too.

eg uTorrent change log: --- 2007-07-04: Version 1.7 (build 3148)

  • Change: Only report downloaded, verified good pieces in tracker announce

Change History (11)

comment:1 Changed 15 years ago by charles

  • Resolution set to fixed
  • Status changed from new to closed

fixed in r2493

comment:2 Changed 15 years ago by charles

  • Component changed from Transmission to libtransmission

comment:3 Changed 15 years ago by charles

  • Resolution fixed deleted
  • Status changed from closed to reopened

comment:4 Changed 15 years ago by charles

  • Resolution set to invalid
  • Status changed from reopened to closed

<xiffix> hi :) Have seen Changeset 2493 - it is not true, that Azureus doesn't report bad/discarded

data to the tracker. The change since refers only to the internal stats of the client. What utorrent did provoked a ban of 1.7.x on several private trackers

undone in r2496.

comment:5 Changed 15 years ago by charles


BTW, here is one paragraph of the reason why - not sure how much lines will transfer:

The BT protocol states that there are 3 numbers involved with stats. Uploaded/downloaded/left. The protocol specs have stated since day one that left cannot be calculated from the torrent size and downloaded as the torrent may be resumed (in which case 0 download) or some pieces may have failed hash checking. In short, downloaded should include the total bytes downloaded including failed pieces. ... uT is now removing failed pieces from the reported download. If you download 500MB of bad data with an old uT version, you get 500MB added to your stats. The same with a new version will show 0MB downloaded. This only works one way. uTorrent continues to report uploaded including any failed pieces. ... This leads to people who report correct stats being viewed as cheats because they claim a total upload amount above the amount of download reported. It also takes away the possibility of spotting any attacks launched by mediasentry or other groups which involve flooding the swarm with bad data.

comment:6 Changed 15 years ago by xiffix

  • Resolution invalid deleted
  • Status changed from closed to reopened

Have to correct the statement i made today via IRC (and Charles quoted it here): Azureus does not report bad/discarded data to the tracker. The dev i talked with corrected himself today - in his first statement he referred to the recent change in the CVS of Azureus, but regarding member's ratio Az behaves like newer µtorrent as well.

Hence i don't see a reason why Transmission or any other client shouldn't do it the same way. Still µtorrent 1.7.2 is banned on several trackers for this behavior (but not Az, speak of double standards...).

Sorry for the confusion i created with forwarding the wrong info.

And i have re-opened the ticket, of course.

comment:7 Changed 15 years ago by charles

<TooMuchTime?> I in fact was rather instrumental in pushing uTorrent to do this. Some of the tracker admins are putting up a fight about it, but it's a done deal. Azureus has just made a change that will in fact report download to due hash fails in a new key in the announce.
<TooMuchTime?> the key wil be called "corrupt"
<TooMuchTime?> as in &corrupt= in the announce
<TooMuchTime?> If you wanted to implement it, I'd suggest going the full Azureus route. That way tracker admins have no cause for complaint as it's their choice if they want to count that bad download. And Azureus has been ignoring this download since November of 2005, it's just that nobody seemed to notice.
<charles_> let me rephrase to make sure I don't go off and write the wrong thing: the "corrupt" key holds the number of corrupt bytes downloaded. "downloaded" lists the number of VALID bytes downloaded. "uploaded" is unchanged.
<TooMuchTime?> Correct.
<TooMuchTime?> and so if some idiot tracker admin wants the "old" behavior, he can always add downloaded+corrupt and use that for the download amount. <charles_> TooMuchTime?: also, do you mind if I attach this conversation to ticket #263 for safekeeping?
<TooMuchTime?> sure, if you like.

comment:8 Changed 15 years ago by charles

(TooMuchTime? is a tracker admin with OiNK.)

comment:9 Changed 15 years ago by charles

<charles_> and the corrupt key only tells the number of corrupt bytes since the 'started' event to the tracker, right?
<TooMuchTime?> yes
<TooMuchTime?> just like uploaded and downloaded
<charles_> it's a simple enough idea. I just want to make sure my notes are good when I go to implement it post-0.80

comment:10 Changed 15 years ago by charles

  • Type changed from Bug Report to Enhancement

comment:11 Changed 14 years ago by charles

  • Milestone changed from Sometime to 0.90
  • Resolution set to fixed
  • Status changed from reopened to closed

Added in r2891

Note: See TracTickets for help on using tickets.