Qbittorrent: ¿Hay alguna forma de bloquear un cliente específico (Thunder)?

Y he utilizado la estrategia de control de congestión de carga anti-chupasangre. (No sé el nombre exacto en inglés)

Aquí hay una bifurcación qBittorrent que puede interesarle, consulte https://github.com/c0re100/qBittorrent-Enhanced-Edition/issues/2

Aquí hay una bifurcación de qBittorrent que puede interesarle, consulte c0re100 # 2

Eso parece bueno.
Pero tengo curiosidad sobre si el qBittorrent de origen está dispuesto a agregar características similares.
Si puedo, prefiero usar una versión oficial en lugar de una versión de terceros.

Creo que sería bueno si podemos establecer algunas reglas para hacer coincidir un cliente y bloquearlo.

Por ejemplo, bloquear a un par cuya ip esté en el rango de xxxx a xxxx, o bloquear a un par cuyo nombre de cliente contenga la cadena 'XL0012', y así sucesivamente.

Incluso podemos escribir un script de usuario para implementar funciones avanzadas.

"Y he utilizado la estrategia de control de congestión de carga anti-chupasangre (no sé el nombre exacto en inglés)".

Anti-sanguijuela es como se llama esa opción en inglés.
Desde este enlace: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"el algoritmo de siembra anti-sanguijuelas se basa en el artículo" Mejorando BitTorrent: un enfoque simple "de Chow et. al. y clasifica a los pares según la cantidad de piezas que tienen, prefiriendo desatascar a los pares que recién comenzaron y a los que están cerca de completando ".
¡Carga MÁS a los clientes Thunder (XunLei) completos al 0% que a los pares aleatorios completos del 5-95%!

Un medio más eficaz de combatir a los pares que no dan nada es habilitar la super siembra "regular" en TODOS los torrents. Los espacios de carga máximos DEBEN ser más bajos que el número de pares conectados o qBitTorrent aún se cargará a todos los pares.
La super siembra estricta es una forma más extrema que no funciona bien en torrents con <5 pares conectados; terminará NO cargándose a buenos pares durante largos intervalos de tiempo.

Desafortunadamente, prohibir manualmente a los pares es necesario si desea seguir subiendo archivos al mínimo. Esto puede requerir la creación de un rango de bloque ipfilter.dat para los peores rangos de IP.

"Y he utilizado la estrategia de control de congestión de carga anti-chupasangre (no sé el nombre exacto en inglés)".

Anti-sanguijuela es como se llama esa opción en inglés.
Desde este enlace: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"el algoritmo de siembra anti-sanguijuelas se basa en el artículo" Mejorando BitTorrent: un enfoque simple "de Chow et. al. y clasifica a los pares según la cantidad de piezas que tienen, prefiriendo desatascar a los pares que recién comenzaron y a los que están cerca de completando ".
¡Carga MÁS a los clientes Thunder (XunLei) completos al 0% que a los pares aleatorios completos del 5-95%!

Un medio más eficaz de combatir a los pares que no dan nada es habilitar la super siembra "regular" en TODOS los torrents. Los espacios de carga máximos DEBEN ser más bajos que el número de pares conectados o qBitTorrent aún se cargará a todos los pares.
La super siembra estricta es una forma más extrema que no funciona bien en torrents con <5 pares conectados; terminará NO cargándose a buenos pares durante largos intervalos de tiempo.

Desafortunadamente, prohibir manualmente a los pares es necesario si desea seguir subiendo archivos al mínimo. Esto puede requerir la creación de un rango de bloque ipfilter.dat para los peores rangos de IP.

Veo. He tomado el nombre de la opción literalmente.

Entonces, significa que no importa si usas el modo 'super seeding' o cambias las opciones, no hay una buena forma en una compilación oficial para bloquearlo, ¿verdad?

Siendo igual que ellos, tampoco quiero subir nada a estos clientes basura.

Estoy usando una versión de terceros ahora, me siento bien.

La super siembra con ranuras de carga limitadas por debajo del máximo de conexiones funciona bien durante más de 1 hora.
Un compañero del 0% obtendrá UNA pieza que pocos / ningún otro compañero tienen y hasta que otros compañeros informen que tienen esa pieza, es poco probable que un compañero del 0% obtenga más cargas de su parte.

Después de leer esta página , entendí cómo funciona el modo súper semilla.

Pero no soy el sembrador inicial, todos los compañeros pueden obtener fácilmente cualquier pieza, así que creo que no me puede ayudar.

La super siembra no requiere que seas el sembrador inicial, solo funciona de manera más eficiente allí, con menos carga duplicada. Pero probablemente no le importe tanto subir la misma pieza a varios compañeros durante un intervalo de 1 hora como subir varias piezas a los clientes de XunLei.

theprogress of the two xunlei client in ur snapshot is 0%, how can they upload to others? brome me?
Ha sido 9102, y algunas personas dicen que Xunlei no lo subirá a otros clientes ...

theprogress of the two xunlei client in ur snapshot is 0%, how can they upload to others? brome me?
Ha sido 9102, y algunas personas dicen que Xunlei no lo subirá a otros clientes ...

Como se muestra en el cliente Xunlei de XL0012, no importa cuánto les cargue, el progreso que informa siempre será del 0% y no le cargará ninguna información.

Si no me cree, vaya a la red pública y descargue algunas semillas al azar. Será claro.

Se cargarán algunas versiones de Thunder (UA es el número de versión de Thunder, no XL0012).

¡Incluso después de 9102, el mal que ha hecho Xunlei no desaparecerá!

"el progreso del cliente de dos xunlei en nuestra instantánea es del 0%, ¿cómo se pueden cargar a otros?"

Mienten sobre su porcentaje completo, afirmando siempre 0% incluso después de que las semillas y los compañeros les hayan subido muchas piezas.

Las versiones anteriores de qBitTorrent (¿aproximadamente 3.0.10 o antes?) Hicieron lo mismo en menor grado, en parte debido a un error y / o descuido de programación.

Activé Strict Super Seeding y configuré Upload Choking Algorithm en Anti-leech. Sin embargo, parece que los clientes de Xunlei inundan el enjambre con conexiones durante las horas pico para torrents populares. La única solución para aumentar las tasas de carga y descarga fue prohibir manualmente las direcciones IP con la etiqueta de cliente "-XL0012 ..." mientras se conectaban, lo cual era bastante laborioso.

ankushnarula, como ya señalé anteriormente en este tema, Anti-leech empeora el problema en lugar de mejorarlo.
Además, el Super Seeding regular es más efectivo que el Strict Super Seeding, tanto para resistir levemente los ataques de sanguijuelas como para tratar con compañeros hostiles.

Es necesario que exista una forma más completa de tratar con los compañeros hostiles. Desafortunadamente, la prohibición de clientes hostiles deberá ser automatizada / automática, pero con un medio para deshabilitarla debido a posibles errores en su lógica.

Perdóname. Entendí mal. Sin embargo, llegué a su conclusión por ensayo y error. También parece que esto no se resolverá de manera justa fuera de un enfoque de consenso distribuido por torrent.

El 24/04/2019 a las 18:46,

ankushnarula, como ya señalé anteriormente en este tema, Anti-leech empeora el problema en lugar de mejorarlo.
Además, el Super Seeding regular es más efectivo que el Strict Super Seeding, tanto para resistir levemente los ataques de sanguijuelas como para tratar con compañeros hostiles.

Es necesario que exista una forma más completa de tratar con los compañeros hostiles. Desafortunadamente, la prohibición de clientes hostiles deberá ser automatizada / automática, pero con un medio para deshabilitarla debido a posibles errores en su lógica.

-
Estás recibiendo esto porque hiciste un comentario.
Responda a este correo electrónico directamente, véalo en GitHub (https://github.com/qbittorrent/qBittorrent/issues/10258#issuecomment-486455764), o silencie el hilo (https://github.com/notifications/unsubscribe-auth / AAAQWM7YZNFLNGHCQWTNR7TPSDPOBANCNFSM4GUKOVLQ).

Lo mismo aquí, prohibir -XL012 manualmente cuando se descarga un torrent público es laborioso, ya que siguen apareciendo a través de dht pex si no se agregan rastreadores de terceros (algunos rastreadores populares están bloqueados en China o bloquean ips chinos). No solo parecen estar al 0% y ocupan una gran parte de su ancho de banda de carga si no se controlan, sino que tampoco dan nada a cambio. Aunque es un problema menor para los usuarios que no están en China, por lo que puedo ver, GFW filtra el tráfico entrante incluso más que el saliente, por lo que Xunlei no puede filtrar de manera tan eficiente.
(Pero hasta donde yo sé, qb no tendrá esta función a menos que libtorrent la implemente).

Tienes razón. ¿Quizás debería publicarlo en el repositorio de libtorrent?

发送 自 Windows 10 版 邮件 应用

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

Lo mismo aquí, prohibir -XL012 manualmente al descargar un torrent público es laborioso. No solo parecen ser del 0%, si no se controlan, por lo general ocupan una gran parte de su ancho de banda de carga, dejando poco para los demás y no dan nada a cambio.
(Pero hasta donde yo sé, qb no tendrá esta función a menos que libtorrent la implemente).
-
Estás recibiendo esto porque eres el autor del hilo.
Responda a este correo electrónico directamente, véalo en GitHub o silencie el hilo.

Ya se menciona en https://github.com/arvidn/libtorrent/pull/3833 , aunque su opinión al respecto es solucionar la laguna legal que se está abusando en lugar de agregar una función de prohibición adicional.

¿Quizás agregar a la lista negra es una forma rápida de bloquear a Xunlei? Solo necesito agregar XL0012 a esa lista negra y qbt bloqueará estos clientes automáticamente. Es fácil de piratear en busca de sanguijuelas, pero a veces puede resultar un poco útil.

theprogress of the two xunlei client in ur snapshot is 0%, how can they upload to others? brome me?
都 ９１０２ 年 了 ， 还有 人 在 说 迅雷 不 上传 给 其他 客户 端 ...

He estado usando qbit durante cuatro años,
y nunca he visto la carga de Thunder (xunlei / XL002).
Incluso si le subo 1 GB, todavía muestra un 0% de progreso,
Solo la versión de velocidad (7.xxx) se cargará a una velocidad de 50 kb o menos.
Hay demasiados usuarios de Thunder, necesitamos una función anti-sangre.
Solo quiero usar la versión oficial.

"Choke deshonesto par en algoritmo anti-siembra de sanguijuelas" se implementó en libtorrent 1.2.1, actualmente hay un qbittorrent 4.2.0RC con libtorrent 1.2.2 liberado, ¿pueden aquellos de ustedes que tengan problemas con Thunder (XunLei) probarlo y pueden ¿Informa si todavía se está cargando?

"Choke deshonesto par en algoritmo anti-siembra de sanguijuelas" se implementó en libtorrent 1.2.1, actualmente hay un qbittorrent 4.2.0RC con libtorrent 1.2.2 liberado, ¿pueden aquellos de ustedes que tengan problemas con Thunder (XunLei) probarlo y pueden ¿Informa si todavía se está cargando?

https://imgur.com/qYKQqfr
todavía subiendo

@cannotbeblank, ¿estás usando un algoritmo anti-sanguijuelas?

@cannotbeblank, ¿estás usando un algoritmo anti-sanguijuelas?

¿Necesitas utilizar esta función? Pensé que estaba bloqueado por defecto.
Estoy usando algoritmo ahora.
pero aún
https://imgur.com/ME9peky

Anti-sanguijuela no solo es ineficaz, hace lo OPUESTO de lo que implica el nombre, como expliqué anteriormente en este hilo.

El método de supersembrado de qBitTorrent (pero no el supersembrado estricto o el sembrado inicial) es más efectivo, pero solo si las ranuras de carga por torrent son menores que las de los pares en ese torrent.

"Choke deshonesto par en algoritmo anti-siembra de sanguijuelas" se implementó en libtorrent 1.2.1, actualmente hay un qbittorrent 4.2.0RC con libtorrent 1.2.2 liberado, ¿pueden aquellos de ustedes que tengan problemas con Thunder (XunLei) probarlo y pueden ¿Informa si todavía se está cargando?

La solución parece no funcionar.

Algoritmo anti-sanguijuelas. Windows 10. qBittorren 4.2.0RC

Por el momento ya he subido más o menos 800KiB al cliente.

Editar - Seguimiento

El cliente acaba de descargar 1 MiB y todavía marca un progreso de 0.0%. En el enjambre otros clientes que han descargado 64 KiB marcan un 0,1% en la columna de progreso.

Editar / 2

Después de reiniciar, no hay rastros de XunLei en el enjambre en este momento.

Editar / 3

XunLei 0012 y 0.0.1.8 aún presentes, aún descargándose, aún marcando un 0% de progreso

Usando Linux y la versión 4.3.0alpha1, todavía se conectan y solo leech. Sin embargo, hubo uno extraño que en realidad mostró algo más del 0% completo.

Parece que el PR arvidn / libtorrent # 3833 no ayuda.

versión de qbittorrent: 4.2.0

El algoritmo de asfixia de carga se ha configurado en "Anti-sanguijuela". (y otros dos algoritmos tampoco ayudan).

Como puede ver, recibió más de 120 MB (actualmente 180 MB antes de la prohibición), lo que significa 30 piezas y el 1,5% de todo el torrent.

Además, en la captura de pantalla, puede ver un par cuyo UA es 7.10.34.360 . Es la versión antigua de Xunlei, lo cual es honesto.

Si un torrent está completamente inundado de conexiones entrantes de las cuales muchas / la mayoría de ellas son sanguijuelas o peores hostiles, intente deshabilitar temporalmente las conexiones entrantes (eliminando el reenvío de puertos / agregando una regla de firewall), DHT y PEX.
... y reduzca el número máximo de conexiones por torrent a un número igual o inferior al número de pares + semillas conectados actualmente. (Esto debería tener el mismo efecto que deshabilitar las conexiones entrantes, pero puede requerir más ancho de banda).

Según wikipedia, Thunder no es compatible con uTP ... o si lo hace, ¡incluso peor que qBitTorrent / libTorrent! Por lo tanto, deshabilitar las conexiones TCP seed + peer debería bloquearlo por completo.
Incluso no permitir conexiones TCP entrantes (solo puerto UDP de reenvío en su enrutador, por ejemplo) debería hacer que se vean con poca frecuencia, porque el Gran Cortafuegos de China bloquea la mayoría de los intentos fuera de China para conectarse a clientes Thunder en China.

Si un torrent está completamente inundado de conexiones entrantes de las cuales muchas / la mayoría de ellas son sanguijuelas o peores hostiles, intente deshabilitar temporalmente las conexiones entrantes (eliminando el reenvío de puertos / agregando una regla de firewall), DHT y PEX.
... y reduzca el número máximo de conexiones por torrent a un número igual o inferior al número de pares + semillas conectados actualmente. (Esto debería tener el mismo efecto que deshabilitar las conexiones entrantes, pero puede requerir más ancho de banda).

Según wikipedia, Thunder no es compatible con uTP ... o si lo hace, ¡incluso peor que qBitTorrent / libTorrent! Por lo tanto, deshabilitar las conexiones TCP seed + peer debería bloquearlo por completo.
Incluso no permitir conexiones TCP entrantes (solo puerto UDP de reenvío en su enrutador, por ejemplo) debería hacer que se vean con poca frecuencia, porque el Gran Cortafuegos de China bloquea la mayoría de los intentos fuera de China para conectarse a clientes Thunder en China.

jajaja
¿Has visto la imagen del comentario anterior ..........?
Thunder soporta uTP desde hace mucho tiempo ,,,,,,

Buen punto ... y sí, me lo perdí. ¿Pero puede hacer STUN con uTP?
... si no, no reenvíe UDP y probablemente no se pueda conectar a la entrada.

Con la ayuda de web api e ipfilter.dat (como Obtener datos de pares torrent y Establecer preferencias de aplicación ), esos clientes pares específicos (como XL0012, Xunlei, cliente: 7.2.) Siguen siendo fáciles de filtrar, aunque no está construido -en función.

Por cierto, teniendo en cuenta los clientes sin ips estáticos, es posible que sea necesario implementar un mecanismo de rotación basado en el tiempo para filtrar ip.

Supongo que todos han pensado en el hecho de que si intentas prohibir clientes específicos, esas personas que codifican ese cliente podrían simplemente hacer o habilitar algo para falsificar su ID de cliente a otro que no es lo que es, por lo que esto realmente no es bueno. 'arreglar' necesariamente? O espero que me equivoque, no codifico mucho.

Odio decirlo, pero tal vez priorice las conexiones de ciertos países, como con un menú desplegable, y luego, además de eso, ¿puede basar las tasas de transferencia en función de la velocidad de transferencia? ¿Pero esto probablemente ha ido más allá de un problema de qBitorrent? Estoy seguro de que tampoco soy el primero en pensar en esto, lo siento.

Con la ayuda de web api e ipfilter.dat (como Obtener datos de pares torrent y Establecer preferencias de aplicación ), esos clientes pares específicos (como XL0012, Xunlei, cliente: 7.2.) Siguen siendo fáciles de filtrar, aunque no está construido -en función.

Por cierto, teniendo en cuenta los clientes sin ips estáticos, es posible que sea necesario implementar un mecanismo de rotación basado en el tiempo para filtrar ip.
¿Puedo obtener una versión perezosa del script?
Solo es necesario prohibir xl0012, el qtorrent de terceros prohíbe todos los Thunder

Odio decirlo, pero tal vez priorice las conexiones de ciertos países, como con un menú desplegable, y luego, además de eso, ¿puede basar las tasas de transferencia en función de la velocidad de transferencia? ¿Pero esto probablemente ha ido más allá de un problema de qBitorrent?

qBitTorrent (o más bien libtorrent que usa qBT) tiene un manejo de pares local que da mayor prioridad o velocidad ilimitada a los ips que determina que son "locales". Tal comportamiento posiblemente podría extenderse a pares de media distancia con tiempos de ping bajos y / o recuento de saltos de traceroute ... y los pares distantes obtendrían una prioridad más baja.
Es probable que este comportamiento deba estar desactivado de forma predeterminada, ya que no todo el mundo lo necesita y el ajuste predeterminado podría ser perjudicial para los enjambres de torrents que no tienen muchos pares Thunder.

Los usuarios de Linux pueden configurar su firewall para filtrar paquetes de estos clientes maliciosos, como una solución temporal.

Por ejemplo:
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

En la mayoría de los casos, esto funcionará, pero a veces todavía puedo ver algunos clientes XL0012 conectados. No estoy seguro de si están haciendo algún tipo de confusión.

En # issuecomment-462029063 , alguien dice:

theprogress of the two xunlei client in ur snapshot is 0%, how can they upload to others? brome me?
都 ９１０２ 年 了 ， 还有 人 在 说 迅雷 不 上传 给 其他 客户 端 ...

Traducción:

Es 2019 ahora, y todavía hay algunas personas que dicen que XunLei (Thunder) no se cargará a otros clientes

都 0202 年 了

Sin embargo, ahora es incluso 2020, y esto es lo que veo:

(un compañero del 0% para siempre)

Sí, Thunder ha lanzado una nueva versión que no es tan malvada, pero todavía hay un número de personas que usan la versión antigua del cliente malvado. Por lo tanto, la función de cliente anti-sanguijuelas y prohibición sigue siendo necesaria.

Actualización: agregar traducción al inglés

Simplemente cambie a bitcomet, que es muy efectivo contra los clientes que Xunlei no carga.Parece que el autor no se tomará el tiempo para resolver el problema de los truenos específico de la procedencia doméstica.

@Phuker @foxdodo Solo en inglés, por favor.

Yo también veo este problema. Clientes con cadena "-XL0012" sanguijuelas y no avanzan en su progreso. Tal vez esté fuera de alcance, pero sería bueno tener una función para bloquear a esos clientes.

Los pasos de los dos clientes Thunder en su instantánea son 0% ¿Cómo pueden cargarlos a otros? [9102], ...

He estado usando qbit durante cuatro años,
Nunca he visto la carga de Thunder (Xunlei / XL002).
Incluso si le envío 1GB, todavía muestra un 0% de progreso, y solo la versión de velocidad (7.xx x) se cargará a una velocidad de 50kb o menos.
Hay demasiados usuarios de Thunder, necesitamos una función anti-sangre.
Solo quiero usar la versión oficial.

Parece cierto, me preocupa que, al usar pt para descargar torrent, el sitio web de pt agrupa la versión mejorada de qbittorrent que funciona para prohibir los truenos (XL0012), pero usar la versión oficial no será así.