[Feature Request] Ability to ban peer with specific name

[Aster-the-Med-Stu]

As mentioned in another issue in qBitTorrent, newer versions of BitTorrent client named Thunder or Xunlei（迅雷） in China, does not upload anything back to other peers. Though we have anti-leeching algorithms, it is not effective enough. I do wish that libtorrent could ban client with speicific name using a regex check, so that those peers beginning with -XL0012- wouldn't get anything from other peers.

[arvidn]

it's not that difficult to write a plugin to do that. or to poll the peer list and ban peers with certain names.
It seems to me though that all it would do would be to encourage clients to lie about their name

[arvidn]

@Aster-the-Med-Stu I would encourage you to, instead, come up with the traits or properties of peers that are abusive that you would want banned. It's definitely possible to sharpen the heuristics of which peers to demote or ban.

This is not trivial though (if it was, it would have been done). Obviously it's important to not ban clients with legitimate behavior.

[RadarNyan]

I've seen some discussion on this issue. The current situation now is: it's HARD to detect those clients with current protocol without simply identify them using the client name.

However, those Thunder/Xunlei clients aren't just leeching clients, they also specifically only upload to the clients of their own. As a result, they can't simply lie about their client name when being blacklisted or they'll lose P2P ability with their own clients as well.

As such, blacklisting by name would be very effective against those Thunder/Xunlei clients, and any other clients behaves in a similar way as long as they have to identify themselves to clients of their own.

[arvidn]

As a result, they can't simply lie about their client name when being blacklisted or they'll lose P2P ability with their own clients as well.

I don't think that's a correct conclusion. clients can communicate who they are in other ways. The peer_id could use a secret HMAC, or something like that.

[Seeker2]

Partial methods to combat Thunder/Xunlei clients...
Manual banning and "regular" super seeding even on downloading torrents is FAR more effective than anti-leech in qBitTorrent:
qbittorrent/qBittorrent#10258 (comment)

They don't use uTP, so disabling TCP effectively blocks them for now:
qbittorrent/qBittorrent#10258 (comment)
...CORRECTION: Thunder/Xunlei uses uTP! But may be partially blocked by not port forwarding UDP.

[arvidn]

I imagine that depends on what performance metrics one use. In a swarm where all peers are well behaved, I would imagine super-seeding would cause a material performance degradation for instance.

[Seeker2]

Why?
If seeding using Super-Seeding is not lowering upload speed significantly below max, I'd expect it to cause no performance decrease at all.
...Unless you mean while also downloading, where it seems possibly even beneficial by rewarding peers that are uploading to other peers.

Or is it because the Thunder/XunLei clients will so poison the swarm by not reporting any HAVE messages that they act as a black hole? (Especially if they make up a large portion of the swarm?)

[arvidn]

Why?

I meant using it all the time, for both downloading and seeding. But come to think of it, perhaps people that are reporting this issue are only referring to this as a problem while they seed, not while they download.

I must admit that I still don't have a good understanding the problem, other than it's a sense of something being "unfair". Is there any performance degradation because of these peers?
Is there something else the upload capacity could be used for that would be better?

[Seeker2]

I personally have only seen a few torrents where Thunder/XunLei clients are common -- and those were expected because the subject was either popular in China or in Chinese. So I would only use super-seeding and/or other tactics on those torrents.

If a torrent swarm has almost entirely leeches on it, Tit-For-Tat obviously won't work and seeds have to provide everything. Seeds will likely not accumulate in number, so download speeds for new peers will likely get worse (as the seed-to-peer ratio worsens due to seeds leaving) to the point that completing the torrent in a timely manner may be impossible. Might as well re-read a paper on BitTorrent poisoners and their effectiveness at shutting down a torrent swarm -- that may not be Thunder/XunLei's intent, but it can be almost the same result!

Upload speed could be better spent uploading to BitTorrent clients that at least offer the possibility of sharing to peers.
It's not fun knowing a semi-busy torrent swarm is likely to die shortly after you quit seeding it.

Even one additional active torrent can have enough demand to "use up" over 10 mbit/second (over 1 MegaBYTE/second) of upload bandwidth -- more than many ISPs offer!

[ywpc]

I've seen some discussion on this issue. The current situation now is: it's HARD to detect those clients with current protocol without simply identify them using the client name.

However, those Thunder/Xunlei clients aren't just leeching clients, they also specifically only upload to the clients of their own. As a result, they can't simply lie about their client name when being blacklisted or they'll lose P2P ability with their own clients as well.

As such, blacklisting by name would be very effective against those Thunder/Xunlei clients, and any other clients behaves in a similar way as long as they have to identify themselves to clients of their own.

This I agree with very much. I think the developers need to be more agressive towards abusive software clients and users.