Jump to content

uTorrent doesn't report stats to peers properly


Borbus

Recommended Posts

I have been seeding a few torrents over the past few days and I have noticed that uTorrent peers do not report their stats (ie. their progress, torrent speed etc.) back to the seed at all. It means that the swarm progress bar in my uTorrent seed does not update and I cannot tell how much of the torrent that peer has.

As for the new uTorrent betas, I am not sure if they are reporting their stats correctly. They seem to be reporting something but it doesn't seem to match up with what they report to the tracker.

So, just to be clear, uTorrent peers do not report their stats to the swarm, only to the tracker.

Link to comment
Share on other sites

It wasn't removed, it was made OPTIONAL and the default was set to false - do not send HAVE messages. I don't know the reason why Ludde did that, but does it really matter now? It has since been changed back to true by default, but the option is still there. :/

Link to comment
Share on other sites

Pardon my quoting the immediately preceding post, but I need to make clear which part of it I'm responding to.

Well, any malicious client can lie and send HAVEs for pieces it doesn't have.

You mean, such as when you pick "Open for Seeding" in µTorrent and the files exist but aren't right and µTorrent just claims to be a seed without checking? Or when you're a seeder running µTorrent but your files have changed and it doesn't recheck pieces before sending, so it just sends out hash-fails?

I don't know the workings of the BT protocol, and I assume that there's a shorthand for telling other peers "I am a seeder" that is different from literally sending a HAVE for every piece, but it's conveying the same information, isn't it, claiming to have pieces that you don't?

Yeah, that still bugs me, µTorrent having a fault that even BitComet doesn't. Yes, I'm aware that nothing will be done about it.

Link to comment
Share on other sites

Yep, even µTorrent would technically be lying if something like that happened. (though the same thing happens with other clients if the data gets modified -after- the re-check, unless they actively check every single piece).

Oh, and BitComet does have it, that's where we got the idea to bypass the hash check from. What's worse is that BitComet reports itself as a seeder if it knows files are missing, but you skipped them.

Link to comment
Share on other sites

But there's mitigation in BitComet, Firon. When you use Open for Seeding in BitComet, it does jump in without checking; but when it starts to send a piece it thinks it has, it rechecks it, sees it doesn't have it, demotes itself to leecher, and does not send a hash-fail. With each piece that it discovers it doesn't really have, it lowers its percentage as it marks them absent. That's the same whether it starts without the files or with files that are a complete mismatch.

So if you try to seed from the wrong directory with BitComet's "open for seeding" function, you find your completion figure starting at 100% and then dwindling on toward 0% (if you're supposed to be the initial seeder).

So that may look weird, but it's better than sending hash-fails out.

ABC and BitTornado do actively recheck every single piece, and they don't have a "jump in without checking" function, but if you do modify the content after starting, they will lower their percentages and not send a hash-fail.

Mainline, Azureus, and µTorrent will merrily send hash-fails if the source is modified after seeding starts, and from what you've told me µTorrent also will if you choose "open for seeding" and the files exist with incorrect data.

Link to comment
Share on other sites

Archived

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

×
×
  • Create New...