Qbittorrent: Existe alguma maneira de bloquear um cliente específico (Thunder)?

E eu usei a estratégia de controle de congestionamento de upload anti-sugador de sangue. (Não sei o nome exato em inglês)

Há um fork qBittorrent aqui que pode ser de seu interesse, consulte https://github.com/c0re100/qBittorrent-Enhanced-Edition/issues/2

Há um fork qBittorrent aqui que pode ser de seu interesse, consulte c0re100 # 2

Isso parece bom.
Mas estou curioso para saber se o qBittorrent de origem está disposto a adicionar recursos semelhantes.
Se eu puder, prefiro usar uma versão oficial em vez de uma versão de terceiros.

Acho que seria bom se pudéssemos definir algumas regras para corresponder a um cliente e bloqueá-lo.

Por exemplo, bloquear um peer cujo ip está na faixa de xxxx a xxxx ou bloquear um peer cujo nome de cliente contém a string 'XL0012' e assim por diante.

Mesmo nós podemos escrever um script de usuário para implementar recursos avançados.

"E eu usei a estratégia de controle de congestionamento de upload anti-sugador de sangue. (Não sei o nome exato em inglês)"

Anti-sanguessuga é como essa opção é chamada em inglês.
Neste link: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"o algoritmo de propagação anti-sanguessuga é baseado no artigo" Improving BitTorrent: A Simple Approach "de Chow et. al. e classifica os pares com base em quantas peças eles têm, preferindo remover os pares que acabaram de iniciar e os que estão próximos de completando. "
Ele carrega MAIS para os clientes Thunder (XunLei) 0% completos do que 5-95% pares completos aleatórios!

Um meio mais eficaz de combater os pares que não dão nada é habilitar a super propagação "regular" em TODOS os torrents. O máximo de slots de upload DEVE ser menor que o número de pares conectados ou o qBitTorrent ainda fará upload para todos os pares.
Super propagação estrita é uma forma mais extrema que não funciona bem em torrents com <5 pares conectados - ela acabará NÃO carregando para bons pares por longos intervalos de tempo.

Banir manualmente os pares é infelizmente necessário se você quiser manter o upload para eles no mínimo. Isso pode exigir a criação de um intervalo de bloco ipfilter.dat para os piores intervalos de IP.

"E eu usei a estratégia de controle de congestionamento de upload anti-sugador de sangue. (Não sei o nome exato em inglês)"

Anti-sanguessuga é como essa opção é chamada em inglês.
Neste link: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"o algoritmo de propagação anti-sanguessuga é baseado no artigo" Improving BitTorrent: A Simple Approach "de Chow et. al. e classifica os pares com base em quantas peças eles têm, preferindo remover os pares que acabaram de iniciar e os que estão próximos de completando. "
Ele carrega MAIS para os clientes Thunder (XunLei) 0% completos do que 5-95% pares completos aleatórios!

Um meio mais eficaz de combater os pares que não dão nada é habilitar a super propagação "regular" em TODOS os torrents. O máximo de slots de upload DEVE ser menor que o número de pares conectados ou o qBitTorrent ainda fará upload para todos os pares.
Super propagação estrita é uma forma mais extrema que não funciona bem em torrents com <5 pares conectados - ela acabará NÃO carregando para bons pares por longos intervalos de tempo.

Banir manualmente os pares é infelizmente necessário se você quiser manter o upload para eles no mínimo. Isso pode exigir a criação de um intervalo de bloco ipfilter.dat para os piores intervalos de IP.

Entendo. Eu entendi o nome da opção literalmente.

Então, isso significa que não importa usar o modo 'super propagação' ou alterar as opções, não há uma boa maneira em uma compilação oficial de bloqueá-la, certo?

Sendo o mesmo que eles, não quero fazer upload de nenhum para esses clientes inúteis também.

Estou usando a versão de terceiros agora, me sentindo bem.

A super propagação com slots de upload limitados a menos do que o máximo de conexões funciona bem ao longo de 1 hora ou mais.
Um par de 0% receberá UM pedaço que poucos / nenhum outro par tem e até que outros colegas relatem ter esse pedaço que o par de 0% provavelmente não obterá mais upload de você.

Depois de ler esta página , entendi como funciona o modo super seed.

Mas eu não sou o semeador inicial, todos os colegas podem facilmente obter qualquer pedaço, então acho que isso não pode me ajudar.

A super semeadura não exige que você seja o semeador inicial, ela apenas funciona com mais eficiência lá - com menos uploads duplicados. Mas você provavelmente não se preocupa tanto em fazer o upload da mesma peça para vários pontos em um intervalo de 1 hora do que fazer o upload de várias peças para clientes XunLei leeching.

o progresso dos dois clientes xunlei em seu instantâneo é 0%, como eles podem fazer upload para os outros? está brincando?
Já foi 9102, e algumas pessoas estão dizendo que Xunlei não fará upload para outros clientes ...

o progresso dos dois clientes xunlei em seu instantâneo é 0%, como eles podem fazer upload para os outros? está brincando?
Já foi 9102, e algumas pessoas estão dizendo que Xunlei não fará upload para outros clientes ...

Conforme mostrado no cliente Xunlei do XL0012, não importa o quanto você carregue para eles, o progresso que ele reporta será sempre 0%, e não carregará nenhuma informação para você.

Se você não acredita em mim, vá à rede pública e baixe algumas sementes aleatoriamente. Ficará claro.

Algumas versões do Thunder (UA é o número da versão do Thunder, não XL0012) serão carregadas.

Mesmo depois de 9102, o mal que Xunlei fez não desaparecerá!

"o progresso dos dois clientes xunlei em seu instantâneo é 0%, como eles podem enviar para outros?"

Eles mentem sobre sua porcentagem de conclusão, alegando sempre 0%, mesmo depois que as sementes e colegas carregaram muitas peças para eles.

Versões mais antigas do qBitTorrent (cerca de 3.0.10 ou antes?) Fizeram a mesma coisa em um grau menor, parcialmente devido a um bug e / ou descuido de programação.

Habilitei o Strict Super Seeding e configurei Upload Choking Algorithm para Anti-leech. No entanto, parece que os clientes Xunlei inundam o enxame com conexões durante os horários de pico para torrents populares. A única solução para aumentar as taxas de download e upload foi banir manualmente os IPs com o rótulo de cliente "-XL0012 ..." enquanto eles se conectavam - o que era bastante trabalhoso.

ankushnarula, como já indiquei anteriormente neste tópico, o Anti-sanguessuga torna o problema pior em vez de melhor.
Além disso, o Super Seeding regular é mais eficaz do que o Strict Super Seeding - tanto para resistir levemente a ataques de sanguessugas quanto para lidar com colegas hostis.

É preciso haver uma maneira mais abrangente de lidar com pares hostis. O banimento de clientes hostis infelizmente precisará ser automatizado / automático, mas com um meio de desabilitá-lo devido a possíveis bugs em sua lógica.

Me perdoe. Eu entendi errado. No entanto, cheguei à sua conclusão por tentativa e erro. Também parece que isso não será resolvido fora de uma abordagem de consenso distribuído por torrent.

Em 24 de abril de 2019 às 18:46,

ankushnarula, como já indiquei anteriormente neste tópico, o Anti-sanguessuga torna o problema pior em vez de melhor.
Além disso, o Super Seeding regular é mais eficaz do que o Strict Super Seeding - tanto para resistir levemente a ataques de sanguessugas quanto para lidar com colegas hostis.

É preciso haver uma maneira mais abrangente de lidar com pares hostis. O banimento de clientes hostis infelizmente precisará ser automatizado / automático, mas com um meio de desabilitá-lo devido a possíveis bugs em sua lógica.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub (https://github.com/qbittorrent/qBittorrent/issues/10258#issuecomment-486455764) ou ignore o tópico (https://github.com/notifications/unsubscribe-auth / AAAQWM7YZNFLNGHCQWTNR7TPSDPOBANCNFSM4GUKOVLQ).

Mesmo aqui, banir -XL012 manualmente ao baixar um torrent público é trabalhoso, pois eles continuam aparecendo através de dht pex se não forem adicionados rastreadores de terceiros (alguns rastreadores populares são bloqueados na China ou bloqueiam ips chineses). Não apenas eles parecem estar em 0% e ocupam uma grande parte da largura de banda de upload se não forem verificados, mas também não dão nada em troca. Embora seja um problema menor para usuários que não estão na China, pelo que eu posso ver, o GFW filtra o tráfego de entrada ainda mais do que de saída, então o Xunlei não pode sugar com a mesma eficiência.
(Mas, até onde eu sei, qb não terá esse recurso, a menos que o libtorrent o implemente.)

Você está certo. Talvez eu deva postar no repositório da libtorrent?

发送 自 Windows 10 版 邮件 应用

发件人: NAVrasZ
发送 时间: 2019 年 5 月 13 日 18:10
收件人: qbittorrent / qBittorrent
抄送: MR; Autor
主题: Re: [qbittorrent / qBittorrent] Existe alguma maneira de bloquear um cliente específico (Thunder)? (# 10258)

Mesmo aqui, banir -XL012 manualmente ao baixar um torrent público é trabalhoso. Além de parecerem 0%, se não forem verificados, geralmente ocupam uma grande parte da largura de banda de upload, deixando pouco para os outros e nada em troca.
(Mas, até onde eu sei, qb não terá esse recurso, a menos que o libtorrent o implemente.)
-
Você está recebendo isso porque é o autor do tópico.
Responda a este e-mail diretamente, visualize-o no GitHub ou ignore a conversa.

Já é referenciado em https://github.com/arvidn/libtorrent/pull/3833 , embora sua opinião sobre isso é corrigir a lacuna que está sendo abusada em vez de adicionar um recurso de proibição extra.

Talvez adicionar à lista negra seja uma maneira rápida de bloquear Xunlei? Eu só preciso adicionar XL0012 a essa lista negra e qbt irá bloquear esses clientes automaticamente. É fácil hackear sanguessugas, mas às vezes pode ser um pouco útil.

o progresso dos dois clientes xunlei em seu instantâneo é 0%, como eles podem fazer upload para os outros? está brincando?
都 ９１０２ 年 了, 还有 人 在 说 迅雷 不 上传 给 其他 客户 端 ...

Eu tenho usado qbit por quatro anos,
e nunca vi upload do Thunder (xunlei / XL002).
Mesmo se eu fizer upload de 1 GB para ele, ele ainda mostra 0% de progresso,
Apenas a versão de velocidade (7.xxx) fará o upload a uma velocidade de 50kb ou menos.
Existem muitos usuários do Thunder, precisamos da função anti-sangue.
Só quero usar a versão oficial.

"sufocar peer desonesto no algoritmo de semeadura anti-leech" foi implementado no libtorrent 1.2.1, atualmente existe um qbittorrent 4.2.0RC com libtorrent 1.2.2 lançado, aqueles de vocês podem ter problemas com o Thunder (XunLei) testá-lo & pode você relata se ainda há algum upload acontecendo ??

"sufocar peer desonesto no algoritmo de semeadura anti-leech" foi implementado no libtorrent 1.2.1, atualmente existe um qbittorrent 4.2.0RC com libtorrent 1.2.2 lançado, aqueles de vocês podem ter problemas com o Thunder (XunLei) testá-lo & pode você relata se ainda há algum upload acontecendo ??

https://imgur.com/qYKQqfr
ainda carregando

@cannotbeblank você está usando um algoritmo anti-sanguessuga ??

@cannotbeblank você está usando um algoritmo anti-sanguessuga ??

Precisa usar este recurso? Achei que estava bloqueado por padrão.
Estou usando um algoritmo agora.
mas ainda
https://imgur.com/ME9peky

Anti-sanguessuga não é apenas ineficaz, ele faz o OPOSTO do que o nome implica - como expliquei anteriormente neste tópico.

O método de super-propagação do qBitTorrent (mas não super-propagação estrita ou propagação inicial) é mais eficaz - mas apenas se os slots de upload por torrent forem menores do que os peers naquele torrent.

"sufocar peer desonesto no algoritmo de semeadura anti-leech" foi implementado no libtorrent 1.2.1, atualmente existe um qbittorrent 4.2.0RC com libtorrent 1.2.2 lançado, aqueles de vocês podem ter problemas com o Thunder (XunLei) testá-lo & pode você relata se ainda há algum upload acontecendo ??

A solução parece não funcionar.

Algoritmo anti-sanguessuga. Windows 10. qBittorren 4.2.0RC

No momento eu já carreguei mais ou menos 800 KiB para o cliente.

Editar - Acompanhamento

O cliente acabou de baixar 1 MiB e ainda marca 0,0% de progresso. No enxame, outros clientes que baixaram 64 KiB marcam 0,1% na coluna de progresso.

Editar / 2

Depois de reiniciar, não há vestígios de XunLei no enxame no momento

Editar / 3

XunLei 0012 e 0.0.1.8 ainda presentes, ainda baixando, ainda marcando 0% de progresso

Usando o Linux e a versão 4.3.0alpha1, eles ainda se conectam e apenas leech. Houve um estranho que realmente mostrou algo mais de 0% concluído.

Parece que o PR arvidn / libtorrent # 3833 não ajuda.

versão qbittorrent: 4.2.0

O algoritmo de bloqueio de upload foi definido como "Anti-leech". (e outros dois algoritmos também não ajudam.)

Como você pode ver, ele recebeu mais de 120 MB (atualmente 180 MB antes de serem banidos), o que significa 30 peças e 1,5% de todo o torrent.

Além disso, na captura de tela, você pode ver um par cujo UA é 7.10.34.360 . É a versão antiga do Xunlei, o que é honesto.

Se um torrent for totalmente inundado com conexões de entrada das quais muitos / a maioria deles são sanguessugas ou piores hostis, tente desabilitar temporariamente as conexões de entrada (removendo o encaminhamento de porta / adicionando uma regra de firewall), DHT e PEX.
... e reduza o máximo de conexões por torrent para igual ou abaixo do número atualmente conectado de peers + seed. (Isso deve ter o mesmo efeito que desativar as conexões de entrada, mas pode ocupar mais largura de banda.)

De acordo com a wikipedia, o Thunder não suporta uTP ... ou se suporta, ainda mais mal do que qBitTorrent / libTorrent! Portanto, desabilitar as conexões TCP seed + peer deve bloqueá-lo completamente.
Mesmo não permitindo conexões TCP de entrada (apenas UDP de encaminhamento de porta em seu roteador, por exemplo) deve torná-las raramente vistas - porque o Grande Firewall da China bloqueia a maioria das tentativas fora da China de se conectar a clientes Thunder na China.

Se um torrent for totalmente inundado com conexões de entrada das quais muitos / a maioria deles são sanguessugas ou piores hostis, tente desabilitar temporariamente as conexões de entrada (removendo o encaminhamento de porta / adicionando uma regra de firewall), DHT e PEX.
... e reduza o máximo de conexões por torrent para igual ou abaixo do número atualmente conectado de peers + seed. (Isso deve ter o mesmo efeito que desativar as conexões de entrada, mas pode ocupar mais largura de banda.)

De acordo com a wikipedia, o Thunder não suporta uTP ... ou se suporta, ainda mais mal do que qBitTorrent / libTorrent! Portanto, desabilitar as conexões TCP seed + peer deve bloqueá-lo completamente.
Mesmo não permitindo conexões TCP de entrada (apenas UDP de encaminhamento de porta em seu roteador, por exemplo) deve torná-las raramente vistas - porque o Grande Firewall da China bloqueia a maioria das tentativas fora da China de se conectar a clientes Thunder na China.

lol
Você viu a imagem do comentário anterior ..........?
Suporte a uTP do Thunder desde há muito tempo ,,,,,,

Bom ponto ... e sim, eu perdi isso. Mas pode fazer STUN com uTP?
... se não, não encaminhe UDP e provavelmente não será possível conectar de entrada.

Com a ajuda da API da web e ipfilter.dat (como Obter dados de pares de torrent e Definir preferências de aplicativo ), esses clientes de pares específicos (como XL0012, Xunlei, cliente: 7.2.) Ainda são fáceis de filtrar, embora não seja um -em recurso.

BTW, considerando aqueles clientes sem ips estáticos, um mecanismo de rotação baseado em tempo de filtragem de ip pode ser necessário para implementar.

Presumo que todos tenham pensado no fato de você tentar banir clientes específicos, aquelas pessoas que codificam aquele cliente poderia apenas fazer ou habilitar algo para falsificar seu ID de cliente para outro que não é o que é, então isso realmente não é uma boa 'consertar' necessariamente? Ou espero que eu esteja errado, eu não faço muita programação.

Eu odeio dizer isso, mas talvez você priorize conexões de certos países, como com um menu suspenso, e além disso, você pode basear as taxas de transferência com base na velocidade de transferência. Mas isso provavelmente foi além de um problema do qBitorrent? Tenho certeza de que não sou o primeiro a pensar nisso também, desculpe.

Com a ajuda da API da web e ipfilter.dat (como Obter dados de pares de torrent e Definir preferências de aplicativo ), esses clientes de pares específicos (como XL0012, Xunlei, cliente: 7.2.) Ainda são fáceis de filtrar, embora não seja um -em recurso.

BTW, considerando aqueles clientes sem ips estáticos, um mecanismo de rotação baseado em tempo de filtragem de ip pode ser necessário para implementar.
Posso obter uma versão preguiçosa do script?
Só precisa banir o xl0012, o qtorrent de terceiros bane todos os Thunder

Eu odeio dizer isso, mas talvez você priorize conexões de certos países, como com um menu suspenso, e além disso, você pode basear as taxas de transferência com base na velocidade de transferência. Mas isso provavelmente foi além de um problema do qBitorrent?

qBitTorrent (ou melhor, libtorrent que qBT usa) tem tratamento de pares local que dá maior prioridade ou velocidade ilimitada para ips que ele determina serem "locais". Tal comportamento poderia ser estendido a pares de meia distância com baixa contagem de pingtimes e / ou traceroute hop ... e pares distantes teriam prioridade mais baixa.
Esse comportamento provavelmente precisa ser definido como OFF por padrão, já que nem todo mundo precisa dele, e ativar esse comportamento pode ser prejudicial para enxames de torrent que não têm muitos pares Thunder.

Os usuários do Linux podem configurar seu firewall para filtrar pacotes desses clientes maliciosos, como uma solução temporária.

Por exemplo:
iptables -I INPUT -p tcp -m string --string XL0012 --algo bm -j DROP
iptables -I INPUT -p udp -m string --string XL0012 --algo bm -j DROP

Na maioria das vezes isso funcionará, mas às vezes ainda consigo ver alguns clientes XL0012 conectados. Não tenho certeza se eles estão fazendo algum tipo de ofuscação.

Em # issuecomment-462029063 , alguém diz:

o progresso dos dois clientes xunlei em seu instantâneo é 0%, como eles podem fazer upload para os outros? está brincando?
都 ９１０２ 年 了, 还有 人 在 说 迅雷 不 上传 给 其他 客户 端 ...

Tradução:

Estamos em 2019 e ainda há quem diga que o XunLei (Thunder) não fará upload para outros clientes

都 0202 年 了

No entanto, agora estamos em 2020 e isso é o que vejo:

(um par permanente de 0%)

Sim, o Thunder lançou uma nova versão que não é tão ruim, mas ainda há várias pessoas usando a versão antiga do cliente maligno. Portanto, o recurso anti-leech e banimento do cliente ainda é necessário.

Atualização: adicionar tradução em inglês

Basta mudar para bitcomet, que é muito eficaz contra clientes que o Xunlei não carrega.Parece que o autor não terá tempo para resolver o problema do trovão específico para proveniência doméstica.

@Phuker @foxdodo Somente em inglês, por favor.

Também estou vendo esse problema. Clientes com a string "-XL0012" sugando e não avançando em seu progresso. Talvez esteja fora do escopo, mas seria bom ter um recurso para bloquear esses clientes.

As etapas dos dois clientes Thunder em seu instantâneo são 0%. Como eles podem fazer upload para outros? [9102], ...

Eu tenho usado qbit por quatro anos,
Nunca vi upload do Thunder (Xunlei / XL002).
Mesmo se eu fizer upload de 1 GB para ele, ele ainda mostra 0% de progresso, e apenas a versão de velocidade (7.xx x) fará upload a uma velocidade de 50kb ou menos.
Existem muitos usuários do Thunder, precisamos da função anti-sangue.
Só quero usar a versão oficial.

parece verdade, estou preocupado com que, ao usar o pt para baixar o torrent, o site pt tenha a versão aprimorada qbittorrent que funciona na proibição do thunder (XL0012), mas usando a versão oficial não será assim.