XD inflates tracker's download count

[anikey]

I posted some torrents on the postman tracker. After I noticed a downloader using XD (or something that self-reported as XD), the download count of the affected torrents got unusually high, way more than the page-hit count (how many times the info page was opened).

Can you please check if that is a bug or what?

Also posted on XD github's discussions: https://github.com/majestrate/XD/discussions/119

[demopan]

It does the same with qbittorrent too, if you close and reopen it. I remember seeding something and for some reason it had a ratio of like 100 for an I2P only torrent. It looks like the amount of peers also doubles on Postman's tracker sometimes.

[lgillis]

We observed something similar four years ago. From the archives:

Request:

The number of downloads is manipulated by a bt-client. The client constantly sends the appropriate signal and the tracker accepts it. I mean it's xd. This way, hundreds of pseudo downloads are created in a short time.

Reply from postman, on 2020-07-18 15:49:31:

Yes, usually it's up to the client to signal the completion of a download. If you know of a reasonable way to verify a client did not really finish a download, but nevertheless announced it, be it by malice or a malfunction, please let me know.

[anikey]

Postman said is not going to create a system to prevent the same client announcing completion of the same torrent multiple times ("because it would be overkill").

But yeah, the fix must certainly be done by the BT clients developers.

[lgillis]

If you don't mind, I'll use this for a brief interim comment.

Such meter readings should not be taken into account. We know, not just since digital social media, that a collection of people generates increased interest from others. It's exactly the same with click numbers. From a certain number of clicks, you have to be there. In your respective social group, this is good form. Outside, you can buy clicks in packages of 1000. At PaT, there have been repeated attempts to artificially boost unpopular content with click counts.

Such meter readings can also easily lure seeds into the populism trap. Intoxicated by their success, they are offering more and more shallow entertainment. Although they originally wanted to distribute food for the brain. If you want to obtain meaningful information, you should do so using the real upload data (in KiB) of your own bt-client.

Everyone hates censuses and nobody wants to be observed. Everyone here wants the greatest possible anonymity. Except when it comes to popular file sharing.

Everyone goes to where what they do is recorded by the accounting department. PaT shows everyone the number of page views and downloads, when the data was uploaded, how many people are actively connected and when the last one left the sinking boat. On its special page, those are crowned, who know best how to take the credit for somebody else's efforts. And that's just the obvious part.

Although there have always been alternatives in the past decades, nothing has changed. Most alternatives have given up after a short time and the few remaining ones lead a shadowy existence. The power of the users to democratically enforce something has been taken away by the users themselves.

[COMiX]

I have the same thing with my test environment with qBitorrent, I2PSnark, BiglyBT and XD

I don't use PaT for my tests and the peers reported on my trackers are never really identical to the torrent clients, even after several weeks without restarting.Sometimes doubled, sometimes nothing on trackers even though I have 10 shares in clients

Java router or I2Pd router, same result

Maybe it's not the torrent clients that are the cause

[cumlord]

i ran into a similar issue once where it surprised me, due to one of the clients (or likely several) being overloaded. There were something like 300 seeds on a single torrent on tracker2 and that couldn't be right. Turns out a couple snarks were hung and they were constantly restarting when they'd disconnect from the router, and every time there's a restart i think with most clients this will cause a new destination to be created for the session.

So on postmans side there's constantly new destinations announcing on the same torrent, so tracker2 assumes they're different clients. Normally this is fine, eventually the old destination will be dropped after the announce interval, but Tracker2 also has a long announce interval (an hour i think?) so it can add up if it's happening a lot during that time

[COMiX]

Further information

I think it's libtorrent that adds the seeders reported by secondary trackers to the seeders of the main tracker. Since XD also relies on these stats, after a while you end up with 25 peers for a torrent that's really only been shared 5 times.

I'm going to try it anyway with a 2400 announcement interval (1800 is too short, peers disappear from trackers, but 3600 seems a bit long in my environment) and the network won't be affected since I'm isolated

[COMiX]

It's confirmed, a 2400 announcement is a very bad idea

Has anyone ever seen XD share a file?
Downloading works, but it never shares anything