client scrapes the tracker too much. Within minutes the client had scraped the tracker over 66 times. Not good on any sites load. Reason why I banned it from my site.

Bug #490706 reported by phonzie
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libtorrent-rasterbar
New
Undecided
auto-arvid
qBittorrent
Triaged
Undecided
Unassigned
Nominated for V2.0.x by phonzie

Bug Description

All the info is in the summary. 66 scrape requests in a few minutes is ridiculous. If it's fixed in a newer version (doubtful if no one actually reads these bug reports) then I would unban it. Other than that, I can't allow it because of the extra load it puts on server.

Revision history for this message
phonzie (ak47shotgun) wrote :

Affected version was qBittorrent v1.5.5 but I can't confirm that 2.0+ still does it. If you can confirm that it doesn't I will simply recommend an update.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Ok. This is indeed a very important thing and I thank you for this report. However, you have to understand that qBittorrent is merely a GUI to libtorrent-rasterbar and I did not add any code to scrape more. Thus I will forward this to libtorrent author.

Revision history for this message
phonzie (ak47shotgun) wrote :

Mmm, nice I didn't actually look into what it was based off of. But yes, when you think about it, it's a huge problem for a client that is intended to be used on all sites. Most upper sites would ban for too much activity. Thanks for the quick reply. Let me know if something happens down the line that addresses the issue.

Revision history for this message
arvid Norberg (arvid-cs) wrote :

please provide more information and ways to reproduce.

How many torrent files were loaded in the client from this tracker?
Were all 66 scrapes for the same info-hash?
Can you provide server logs for them?
How can I reproduce this?

Revision history for this message
phonzie (ak47shotgun) wrote :

1) Not sure the user was only seeding one torrent (at least at my site).
2) Yes all 66 were for the same torrent. (There were many more than 66 i just banned the client and disabled the script that was recording scrapes.)
3) http://pastebin.com/d4d978089 the etc.. marks a point where I got tired of copy/pasting from the accesslog meaning there were plenty more in between but i thought you should know the frequency of the announce times compared to scrapes.
4) Use wireshark while seeding is the best way I can recommend.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Arvid, I subscribed you to this report because I don't think you got phonzie's reply.

Changed in qbittorrent:
status: New → Triaged
Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Arvid, note that I never call torrent_handle::scrape_tracker() manually in qBittorrent code (I have greped it to be sure).

Revision history for this message
arvid Norberg (arvid-cs) wrote :

Surely running wireshark wouldn't trigger libtorrent to scrape more often.

Chris, what is your session_settings::auto_scrape_interval set to?

Revision history for this message
phonzie (ak47shotgun) wrote :

I meant to run wireshark to see how much activity is going on, not saying that's the cause. I don't believe there would be any special circumstances for the scrape to act like this. Looks to mean like normal running activity, just way too much of it. Most times less than 20 seconds between each scrape.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Arvid:
$ grep -r "auto_scrape_interval" src/
Binary file src/bittorrent.o matches
Binary file src/qbittorrent matches

I'm not setting it so it is libtorrent's default.

Revision history for this message
arvid Norberg (arvid-cs) wrote :

unless you link against a different version of compiled libtorrent than you compile against. If the session_settings layout changed, you may be setting a different value that gets interpreted as the auto_managed_interval

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

According to libtorrent source, default is:
./include/libtorrent/session_settings.hpp: , auto_scrape_interval(1800)

So every 30 min?

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Well, in that case it would be the user's fault...

I will check with wireshark here in any case to see what the normal behavior is.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Indeed, I cannot reproduce it while using wireshark.

Revision history for this message
phonzie (ak47shotgun) wrote :

I can't see a user modifying an application simply to scrape more often, and (I don't know because I haven't used the gui) I don't think that the gui has a manual scrape option that the user was pressing every 20-40 seconds for over 2 days. (Mind you I only recorded 66 in the sql database before banning the client), but the log shows many many more over the course of the day that log was taken.

Revision history for this message
arvid Norberg (arvid-cs) wrote :

I think the soname of the dll is supposed to prevent applications to link to incompatible versions as well.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Did you notice this behavior with other qBittorrent users?

If you saw only this for one user, this is not exactly evidence of a bug/misbehavior in qBittorrent/libtorrent. Note that Deluge client also uses libtorrent as a backend.

I don't think this is the best response to ban all the users of a client if problems have been noticed with one user (especially with Free Software.. Who knows what the user may have introduced in the code).

There is no way in qBittorrent UI to alter the scraping frequency and there is no button either to manually scrape a tracker. I don't even alter libtorrent's default value (which is every 30 min, and which is what I see with wireshark here).

Revision history for this message
phonzie (ak47shotgun) wrote :

It's was a new feature to start recording the number of scrapes, (only added it in yesterday). I've only had 3 unique users ever using qBittorrent, so I can't really give you any more info than i've already got. Seems as though the client was modified or something was missed. Either way, it stays banned until further notice. Thanks for your support.

Revision history for this message
Christophe Dumez (hydr0g3n) wrote :

Well, this is too bad. As you can imagine, I'm quite disappointed with this result. I don't see what I could do to solve the situation.

I don't approve of banning clients based on a single user's behavior. This is unfair to this client and unfortunately too many tracker owners are acting like you. qBittorrent (or libtorrent) has never been considered as harmful to the Bittorrent network. qBittorrent is relatively recent and it obviously won't help to its popularity when trackers are using whitelisting (of only the most popular clients) or are banning clients on such short notice/evidence.

Revision history for this message
phonzie (ak47shotgun) wrote :

Like I said, for now it is banned. I am continuing to collect stats on usage. Should I notice that this is an isolated (user-specific) incident, I will release the ban and simply kill the user (not for real). It's nothing against you or your client, we will see how it folds out in the near future, meanwhile don't loop me into the stereotype (if there even is one) of this "Elitist" tracker sysop whereas I'm just doing what's best for the tracker, not intentially trying to sabotage the usage of your work in any way. As a fellow coder, I can relate to what you think when your entire series of programs is "banned" from use. I'm doubtful that it will remain as such.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.