qBittorrent
qBittorrent copied to clipboard
qbittorrent
Is there any way to block a specific client (Thunder)?
In China, a download software named Thunder (XunLei) is very popular. But it won't upload even just a bit of data, reporting its progress is 0%, and it is always the fastest leecher in peer list, which made me angry.
To avoid being blocked, its client name is -XL0012- with some random strings.
Here is an example:
I have to right click it and block the IP manually. But it is impracticable due to its a large number of users.
We really need some effective methods to solve this problem.
qBittorrent version and Operating System
qbittorrent 4.1.5 running on Win10 1803.
And I have used the anti-bloodsucking upload congestion control strategy. (I don't know the English exact name)
There's a qBittorrent fork here that you may be interested in, see https://github.com/c0re100/qBittorrent-Enhanced-Edition/issues/2
There's a qBittorrent fork here that you may be interested in, see c0re100#2
That seems good. But I am curious about if the origin qBittorrent is willing to add similar features. If I can, I prefer to use an official version instead of a 3rd-party version.
I think it will be nice if we can set some rules to match a client and block it.
Such as, blocking a peer whose ip is in range from x.x.x.x to x.x.x.x, or blocking a peer whose client name contains string 'XL0012', and so on.
Even we can write a userscript to implement advanced features.
"And I have used the anti-bloodsucking upload congestion control strategy. (I don't know the English exact name)"
Anti-leech is what that option is called in English. From this link: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp "the anti-leech seeding algorithm is based on the paper "Improving BitTorrent: A Simple Approach" from Chow et. al. and ranks peers based on how many pieces they have, preferring to unchoke peers that just started and peers that are close to completing." It uploads MORE to the 0% complete Thunder (XunLei) clients than 5-95% complete random peers!
A more effective means of combating peers that give nothing is enabling "regular" super seeding on ALL torrents. Max upload slots MUST be lower than number of connected peers or qBitTorrent will still upload to every peer. Strict super seeding is a more extreme form that does not work well on torrents with <5 connected peers -- it will end up NOT uploading to good peers for long intervals of time.
Manually banning the peers is unfortunately necessary if you want to keep uploading to them to a minimum. This may require creating an ipfilter.dat block range for the worst ip ranges.
"And I have used the anti-bloodsucking upload congestion control strategy. (I don't know the English exact name)"
Anti-leech is what that option is called in English. From this link: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp "the anti-leech seeding algorithm is based on the paper "Improving BitTorrent: A Simple Approach" from Chow et. al. and ranks peers based on how many pieces they have, preferring to unchoke peers that just started and peers that are close to completing." It uploads MORE to the 0% complete Thunder (XunLei) clients than 5-95% complete random peers!
A more effective means of combating peers that give nothing is enabling "regular" super seeding on ALL torrents. Max upload slots MUST be lower than number of connected peers or qBitTorrent will still upload to every peer. Strict super seeding is a more extreme form that does not work well on torrents with <5 connected peers -- it will end up NOT uploading to good peers for long intervals of time.
Manually banning the peers is unfortunately necessary if you want to keep uploading to them to a minimum. This may require creating an ipfilter.dat block range for the worst ip ranges.
I see. I have taken the option name literally.
So, it means that no matter using 'super seeding' mode or changing options, there's no good way on an official build to block it out, right?
Being the same as them, I don't want to upload any a bit to these junk clients, too.
I 'm using 3rd-party version now, feeling good.
Super seeding with upload slots limited lower than max connections works well over 1+ hour time. A 0% peer will get ONE piece that few/no other peers have and until other peers report having that piece that 0% peer is unlikely to get any more upload from you.
Having read this page, I understood how the super seed mode works.
But I am not the initial seeder, all peers can easily get any pieces, so I think it can't help me.
Super seeding doesn't require you being the initial seeder, it just works more efficiently there -- with less duplicate uploading. But you probably don't care as much about uploading the same piece to multiple peers over a 1 hour interval than uploading multiple pieces to leeching XunLei clients.
theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me? 都９１０２年了，还有人在说迅雷不上传给其他客户端...
theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me? 都９１０２年了，还有人在说迅雷不上传给其他客户端...
如图这种XL0012的迅雷客户端，不论你上传多少给他们，他回报的进度永远是0%，并且不会上传任何信息给你。
不信你自己去公网随便下载几个种子，就清楚了。
有些版本的迅雷(UA是迅雷的版本号，而不是XL0012)，是会上传的。
即使是9102年了，迅雷做过的恶依然不会消失！
"theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?"
They lie about their percentage complete, claiming always 0% even after seeds and peers have uploaded many pieces to them.
Older versions of qBitTorrent (about 3.0.10 or before?) did the same thing to a lesser degree, partially due to a bug and/or programming oversight.
I enabled Strict Super Seeding and set Upload Choking Algorithm to Anti-leech. However, it seems the Xunlei clients flood the swarm with connections during peak times for popular torrents. Only solution for increasing download and upload rates was to manually ban IPs with client label "-XL0012..." as they connected - which was quite laborious.
ankushnarula, as I already pointed out earlier in this issue thread, Anti-leech makes the problem worse instead of better. Also, regular Super Seeding is more effective than Strict Super Seeding -- both in slightly resisting leech attacks and in dealing with hostile peers.
There needs to be a more comprehensive manner of dealing with hostile peers. Banning hostile clients will unfortunately need to be automated/automatic, but with a means to disable that due to possible bugs in its logic.
Forgive me. I misunderstood. However, I arrived at your conclusion via trial and error. It also seems this won’t be solved fairly outside a per torrent distributed consensus approach.
On Apr 24, 2019 at 18:46, <Seeker2 (mailto:[email protected])> wrote:
ankushnarula, as I already pointed out earlier in this issue thread, Anti-leech makes the problem worse instead of better. Also, regular Super Seeding is more effective than Strict Super Seeding -- both in slightly resisting leech attacks and in dealing with hostile peers.
There needs to be a more comprehensive manner of dealing with hostile peers. Banning hostile clients will unfortunately need to be automated/automatic, but with a means to disable that due to possible bugs in its logic.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub (https://github.com/qbittorrent/qBittorrent/issues/10258#issuecomment-486455764), or mute the thread (https://github.com/notifications/unsubscribe-auth/AAAQWM7YZNFLNGHCQWTNR7TPSDPOBANCNFSM4GUKOVLQ).
Same here, banning -XL012 manually when downloading a public torrent is laborious as they keep popping up through dht pex if not added third party trackers (some popular trackers either are blocked in China or block Chinese ips). Not only do they appear to be at 0% and occupy a huge portion of your upload bandwidth if left unchecked, but also give none in return. Though it's less a problem for users that are not in China, as far as I can see GFW filters inbound traffic even more than it does outbound so Xunlei can't leech as efficiently. (But as far as I know, qb won't have this feature unless libtorrent implements it.)
You are right. Maybe I should post it to libtorrent’s repo?
发送自 Windows 10 版邮件应用
发件人: NAVrasZ 发送时间: 2019年5月13日 18:10 收件人: qbittorrent/qBittorrent 抄送: MR; Author 主题: Re: [qbittorrent/qBittorrent] Is there any way to block a specificclient (Thunder)? (#10258)
Same here, banning -XL012 manually when downloading a public torrent is laborious. Not only do they appear to be 0%, if left unchecked they usually occupy a huge portion of your upload bandwidth, leaving little for others and give none in return. (But as far as I know, qb won't have this feature unless libtorrent implements it.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.
It's already referenced in https://github.com/arvidn/libtorrent/pull/3833, tho their take on this is to fix the loophole that is being abused instead of adding an extra ban feature.
Maybe adding to blacklist is a fast way to block Xunlei? I just need to add XL0012 to that blacklist and qbt will block these clients automatically. It is easy to hack for leeches but sometimes may be a little bit useful.
theprogress of the two xunlei client in ur snapshot is 0% ,how can they upload to others?kidding me? 都９１０２年了，还有人在说迅雷不上传给其他客户端...
I have been using qbit for four years , and I have never seen Thunder upload (xunlei/XL002). Even if I upload 1GB to him, he still shows 0% progress, Only the speed version (7.x.x.x) will upload at a speed of 50kb or less. There are too many Thunder users, we need anti-blood function. Just want to use the official version.
"choke dishonest peer in anti-leech seeding algorithm" has been implemented in libtorrent 1.2.1, currently there is a qbittorrent 4.2.0RC with libtorrent 1.2.2 released, can those of you having issues with Thunder (XunLei) test it & can you report if there is any uploading happening still??
"choke dishonest peer in anti-leech seeding algorithm" has been implemented in libtorrent 1.2.1, currently there is a qbittorrent 4.2.0RC with libtorrent 1.2.2 released, can those of you having issues with Thunder (XunLei) test it & can you report if there is any uploading happening still??
https://imgur.com/qYKQqfr still uploading
@cannotbeblank are you using anti-leech algorithm??
Need to use this feature? I thought it was blocked by default. I am using algorithm now. but still https://imgur.com/ME9peky
Anti-leech is not only ineffective, it does the OPPOSITE of what the name implies -- as I explained earlier on this thread.
qBitTorrent's Super-seeding method (but not strict super-seeding or initial seeding) is more effective -- but only if upload slots per torrent is less than peers on that torrent.
"choke dishonest peer in anti-leech seeding algorithm" has been implemented in libtorrent 1.2.1, currently there is a qbittorrent 4.2.0RC with libtorrent 1.2.2 released, can those of you having issues with Thunder (XunLei) test it & can you report if there is any uploading happening still??
The solution seems not working.
Anti-leech algorithm. Windows 10. qBittorren 4.2.0RC
At the moment I've already uploaded more or less 800KiB to the client.
Edit - Follow-up
The client has just downloaded 1 MiB and still marks 0.0% progress. In the swarm other clients which have downloaded 64 KiB marks 0.1% in the progress column.
Edit/2
After rebooting no traces of XunLei in the swarm at the moment
Edit/3
XunLei 0012 and 0.0.1.8 still present, still downloading, still marking 0 % progress
Using Linux & version 4.3.0alpha1, they still connect & only leech. There was one odd one who actually showed something more than 0% complete though.
It seems that the PR arvidn/libtorrent#3833 doesn't help.
qbittorrent version: 4.2.0
Upload choking algorithm has been set to "Anti-leech". (and other two algorithm don't help too.)
As you can see, it received more than 120MB (currently 180MB before banned), which means 30 pieces and 1.5% of the entire torrent.
Additionally, In the screenshot, you can see a peer whose UA is 7.10.34.360. It is the old version of Xunlei, which is honest.
If a torrent is utterly flooded with incoming connections of which many/most of them are leeches or worse hostiles, try temporarily disabling incoming connections (by removing port forwarding/adding a firewall rule), DHT and PEX. ...and reduce max connections per torrent to equal or below the currently connected number of peers+seeds. (This should have the same effect as disabling incoming connections, but may take more bandwidth.)
According to wikipedia, Thunder doesn't support uTP ...or if it does, even more poorly than qBitTorrent/libTorrent does! So disabling TCP seed+peer connections should block it completely. Even not allowing incoming TCP connections (only port forward UDP on your router for example) should make them rarely seen -- because the Great Firewall of China blocks most outside-of-China attempts to connect to Thunder clients in China.
If a torrent is utterly flooded with incoming connections of which many/most of them are leeches or worse hostiles, try temporarily disabling incoming connections (by removing port forwarding/adding a firewall rule), DHT and PEX. ...and reduce max connections per torrent to equal or below the currently connected number of peers+seeds. (This should have the same effect as disabling incoming connections, but may take more bandwidth.)
According to wikipedia, Thunder doesn't support uTP ...or if it does, even more poorly than qBitTorrent/libTorrent does! So disabling TCP seed+peer connections should block it completely. Even not allowing incoming TCP connections (only port forward UDP on your router for example) should make them rarely seen -- because the Great Firewall of China blocks most outside-of-China attempts to connect to Thunder clients in China.
LOL Have you seen previous comment's image..........? Thunder support uTP since long time ago,,,,,,
