Opened 13 years ago

Closed 12 years ago

#1917 closed Bug (duplicate)

webseed downloads don't factor into overall progress, slower compared to BitTorrent

Reported by: ryan Owned by: charles
Priority: Normal Milestone: None Set
Component: libtransmission Version: 1.51
Severity: Major Keywords: patch-needed
Cc:

Description

I'm looking to distribute files over an intranet using libtransmission as a client. To seed the swarm, we have a handful of apache2 webservers hosting the files. With the Mac GUI, it appears that Transmission 1.51 cannot download from the webseeds, as almost zero progress is made as long as it's only downloading from the seeds.

I dug into this further with the 1.51 sources, and it seems that blocks are being downloaded, they just never reflect in the download's progress. Only when peers are introduced to the mix do downloads actually appear to progress.

The CLI seems better about percent progress, but the webseed download rate never factors into the download rate; that rate seems to be peer only.

I've attached a torrent file (install-x86-minimal-2008.0.broken.torrent) which can reproduce this issue. It's a generic Gentoo linux torrent file modified thus:

1) The tracker has a typo, so it won't resolve. The hostname is torrents.gentoi.org rather than torrents.gentoo.org 2) All url-list hosts are removed except for two which I know have the file and return data when curled

When you open this torrent file in Transmission's Mac OS X GUI or the CLI, the web hosts rarely provide data. According to the gui, I've gotten 101.9K over the past 10 minutes. However, opening this in BitTorrent? 4.27.2, I get ~56KB/s.

If you remove the existing download from Transmission and load the torrent with a working tracker (install-x86-minimal-2008.0.correct.torrent), you'll find that it suddenly discovers a lot of data *has* been downloaded. Something about adding the tracker and peers back in the mix seems to force the lib to realize it has downloaded data.

Alternatively, if you open the "broken" torrent with the CLI, you'll see that data is downloaded (at a rate seemingly slower than BitTorrent?'s, but that's hard to judge since no rate is provided).

Attachments (2)

install-x86-minimal-2008.0.broken.torrent (51.2 KB) - added by ryan 13 years ago.
Gentoo torrent modified so the tracker URL never resolves and the url-list webseeds must be relied upon
install-x86-minimal-2008.0.correct.torrent (51.2 KB) - added by ryan 13 years ago.
Gentoo torrent modified so only two correct, known good webseeds are used (the default torrent only has broken webseed urls for some reason)

Download all attachments as: .zip

Change History (11)

Changed 13 years ago by ryan

Gentoo torrent modified so the tracker URL never resolves and the url-list webseeds must be relied upon

Changed 13 years ago by ryan

Gentoo torrent modified so only two correct, known good webseeds are used (the default torrent only has broken webseed urls for some reason)

comment:1 Changed 12 years ago by ryan

Did some more debugging on this today. The Mac client references the torrent struct's pieceDownloadSpeed value, to report download speeds. Seems logical.

bandwidth.c's getSpeed() doesn't register *any* data obtained from a web seed. Conversely, ratecontrol.c's rateForInterval() returns apparently valid data. Odd.

I admit, I'm very confused as to why there're separate bandwidth and ratecontrol systems and as to why the implementation of those two functions is identical yet they reference different download stats. Since I'm totally new to the code base, I guess the former might be limiting overall bandwidth while the latter would be concerned with swarm bandwidth? Of course, if that were the case, I'd expect my findings to be the opposite -- getSpeed() should register webseed bandwidth while rateForInterval() would return nothing if only webseeds were used.

I'll dig into this more in a bit.

comment:2 Changed 12 years ago by ryan

  • Version changed from 1.51 to 1.60

comment:3 Changed 12 years ago by charles

  • Version changed from 1.60 to 1.51

1.51 is the first version where this was reported...

comment:4 Changed 12 years ago by charles

ratecontrol is something of an artifact that iirc is only used by the webseed code.

honestly if you were to nuke the webseed code and rebuild from scratch it wouldn't bother me a bit.

comment:5 Changed 12 years ago by charles

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

There is only one developer currently working on libtransmission, and webseeds are a low priority because webseed .torrents are exceedingly rare. Unless they catch on more in the BitTorrent? world, this ticket is unlikely to be implemented.

This ticket would be an improvement to Transmission, at least to the extent that webseeds are used, so patches are welcomed. If someone out there feels strongly about webseeds, please attach a patch to this ticket and reopen the ticket. Thanks!

comment:6 Changed 12 years ago by livings124

Reopening because this is a valid issue that should be fixed sometime or other.

comment:7 Changed 12 years ago by livings124

  • Resolution wontfix deleted
  • Status changed from closed to reopened

comment:8 Changed 12 years ago by charles

  • Keywords patch-needed added

comment:9 Changed 12 years ago by charles

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

Closing this ticket as a duplicate of #2022

Note: See TracTickets for help on using tickets.