"Seeds" and "Peers" info in uTorrent

[Yuri Testikov]

From what I understand, Peers = Seeders + Leechers, so seeders are peers to.
Peers number can't be lower than Seeders number. But, on some torrents, uTorrent reports more seeders than peers. On a seeding torrent I got something like that: Seeds 0(6) - Peers 0(1). If it's only one peer how can be 6 seeders ? Maybe uTorrent confuse Peers with Leechers...

[cirulilu]

in utorrents there are seeds and peers(leechers). seeders are peers too, but utorrent classifies only leechers as peers.

[alpacino]

I think the term "leecher" is unofficial. The correct is seeders a peers only. So that said, yes, peers number can be lower than seeders. In your situation, you and 5 more seeders are available, while there's is one 1 peer.

[RedHawk]

Seeds displays the number of seeds you are connected to, and the number of seeds in the swarm in the parentheses. The number in the swarm is collected from the tracker and other methods of exchanging peers, such as DHT or Peer Exchange.
Peers displays the number of peers you are connected to, and the number of peers in the swarm in the parentheses. The number in the swarm is collected from the tracker and other methods of exchanging peers, such as DHT or Peer Exchange.

[anon]

I think the term "leecher" is unofficial. The correct is seeders a peers only. So that said, yes, peers number can be lower than seeders. In your situation, you and 5 more seeders are available, while there's is one 1 peer.

It's even more complicated than that

The specification says a "peer" is everyone in the swarm of a particular torrent. This would include seeders and leechers, as Yuri Testikov assumed. The term "leechers" only appears thrice (twice between quotation marks, which suggests it's indeed unofficial), and announce and scrape responses divide peers between those who are "complete" and those "incomplete".

I say it doesn't matter which words you use, as long as the meaning is clear from context.

[alpacino]

Thanks for the correction my friend! It's pretty clear now.

Now I have a good question for you: how does the client know how much peers there are on trackers that don't support scrape?

[anon]

Now I have a good question for you: how does the client know how much peers there are on trackers that don't support scrape?

The amount of "complete" and "incomplete" peers can also be returned as part of the announce response. Technically speaking, scraping just a less heavy form to get that same information, that can also get a "downloaded" value (how many people claimed to complete the torrent) and support multiple requests in a single connection.

If the numbers aren't available through either channel, clients typically classify all the peers received as non-seeders and then sort them out as they connect to each.

[alpacino]

Cheers for the info

Ever wondered why RM and mR can't do the last method you described? Is it any technical restriction?

[anon]

Ever wondered why RM and mR can't do the last method you described? Is it any technical restriction?

You mean scraping or sorting peers individually?

Every client is different in terms of how and how often it scrapes, so rather than introducing a possible detection vector, it was easier and safer to not implement it and tell people to turn the feature off in their clients.

As for the other thing, these programs don't connect to peers so they can't send the protocol messages needed to know who's who. RM+ does send a choke message (which basically means "sorry, can't talk right now") on incoming connections to make things realistic and have some plausible deniability, but that's about it.

Both cases could be implemented, they're just extra work for little gain.

[alpacino]

I meant sorting peers individually, because I knew RM already had "scrape" functions from the get go, but it wasn't a good option to let ticked when using it because as you said, every client scrapes in it's own way, so one should use the RM's scrape function manually, to avoid raising flags.

My point here really is the problem you have when using tools (RM, RM+ and mR) on trackers who don't support scrape and rely solely on identifying peers individually on the first announce, as you lose some automation, since you have to keep an eye on the tracker itself to see and have an idea how the swarm is going, how many peers and all that. In sight of this, do you really think it would be little gain?

[anon]

The problem is that even if all trackers supported scraping and the two things I mentioned before were a non-issue, this:

keep an eye on the tracker itself to see and have an idea how the swarm is going, how many peers and all that

Would still be the best way to really know if a torrent is (still) good for cheating.

Firstly, since communication with the tracker is interval-based, there is no method to get the status of a swarm with 100% certainty in real time. Even the tracker itself can't know about peers that had a network or power failure and are no longer there, or ghostleechers that changed their address and are downloading off the record.

Secondly, even if a cheating program did connect to peers to check their status, that would scale horribly. It would have to constantly send and receive messages to everyone, and would not be guaranteed to achieve it (see Not connected to any seeds - VuzeWiki), thus making it still not completely reliable.

Normally, this would be mostly irrelevant. Just leave your client open and you'll upload if you have to. But you can't really automate cheating based on this information, because by the time your program learns no one is downloading anymore and stops fake uploading, it may already be too late.