Qbittorrent: 특정 클라이언트(Thunder)를 차단하는 방법이 있습니까?

그리고 안티-혈액 업로드 혼잡 제어 전략을 사용했습니다. (정확한 영어 이름은 모르겠다)

여기에 관심이 있을 수 있는 qBittorrent 포크가 있습니다. https://github.com/c0re100/qBittorrent-Enhanced-Edition/issues/2를 참조

여기에 관심이 있을 수 있는 qBittorrent 포크가 있습니다. c0re100#2를 참조하십시오

좋은 것 같습니다.
하지만 오리진 qBittorrent가 비슷한 기능을 추가할 의향이 있는지 궁금합니다.
가능하면 타사 버전 대신 공식 버전을 사용하는 것을 선호합니다.

클라이언트와 일치하는 규칙을 설정하고 차단할 수 있으면 좋을 것 같습니다.

예를 들어 ip가 xxxx에서 xxxx 사이인 피어를 차단하거나 클라이언트 이름에 문자열 'XL0012'가 포함된 피어를 차단하는 등의 작업이 있습니다.

고급 기능을 구현하기 위해 사용자 스크립트를 작성할 수도 있습니다.

"그리고 피를 빨지 않는 업로드 혼잡 제어 전략을 사용했습니다. (정확한 영어 이름은 모릅니다)"

안티 거머리는 그 옵션을 영어로 부르는 것입니다.
이 링크에서: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"Anti-leech seeding algorithm은 Chow et. al.의 "Improving BitTorrent: A Simple Approach" 논문을 기반으로 하며 그들이 가지고 있는 조각의 수를 기반으로 피어 순위를 매기며 방금 시작한 피어와 가까운 피어를 선호합니다. 완료."
5-95%의 완전한 무작위 피어보다 0%의 완전한 Thunder(XunLei) 클라이언트에 더 많이 업로드합니다!

아무것도 제공하지 않는 피어와 싸우는 더 효과적인 방법은 모든 급류에서 "일반" 슈퍼 시딩을 활성화하는 것입니다. 최대 업로드 슬롯은 연결된 피어의 수보다 작아야 합니다. 그렇지 않으면 qBitTorrent가 여전히 모든 피어에 업로드됩니다.
엄격한 슈퍼 시딩은 연결된 피어가 5명 미만인 급류에서 잘 작동하지 않는 보다 극단적인 형태입니다. 결국 오랜 시간 동안 좋은 피어에 업로드되지 않게 됩니다.

피어에 대한 업로드를 최소한으로 유지하려면 불행히도 피어를 수동으로 금지해야 합니다. 이것은 최악의 IP 범위에 대한 ipfilter.dat 블록 범위를 생성해야 할 수도 있습니다.

"그리고 피를 빨지 않는 업로드 혼잡 제어 전략을 사용했습니다. (정확한 영어 이름은 모릅니다)"

안티 거머리는 그 옵션을 영어로 부르는 것입니다.
이 링크에서: https://github.com/arvidn/libtorrent/blob/master/src/choker.cpp
"Anti-leech seeding algorithm은 Chow et. al.의 "Improving BitTorrent: A Simple Approach" 논문을 기반으로 하며 그들이 가지고 있는 조각의 수를 기반으로 피어 순위를 매기며 방금 시작한 피어와 가까운 피어를 선호합니다. 완료."
5-95%의 완전한 무작위 피어보다 0%의 완전한 Thunder(XunLei) 클라이언트에 더 많이 업로드합니다!

아무것도 제공하지 않는 피어와 싸우는 더 효과적인 방법은 모든 급류에서 "일반" 슈퍼 시딩을 활성화하는 것입니다. 최대 업로드 슬롯은 연결된 피어의 수보다 작아야 합니다. 그렇지 않으면 qBitTorrent가 여전히 모든 피어에 업로드됩니다.
엄격한 슈퍼 시딩은 연결된 피어가 5명 미만인 급류에서 잘 작동하지 않는 보다 극단적인 형태입니다. 결국 오랜 시간 동안 좋은 피어에 업로드되지 않게 됩니다.

피어에 대한 업로드를 최소한으로 유지하려면 불행히도 피어를 수동으로 금지해야 합니다. 이것은 최악의 IP 범위에 대한 ipfilter.dat 블록 범위를 생성해야 할 수도 있습니다.

알 겠어요. 옵션 이름을 문자 그대로 가져왔습니다.

따라서 '수퍼 시딩' 모드를 사용하거나 옵션을 변경하더라도 공식 빌드에서 이를 차단할 좋은 방법이 없다는 뜻이겠죠?

그들과 같기 때문에 이 정크 클라이언트에게도 조금도 업로드하고 싶지 않습니다.

나는 지금 기분이 좋은 타사 버전을 사용하고 있습니다.

업로드 슬롯이 최대 연결보다 낮게 제한된 슈퍼 시딩은 1시간 이상 동안 잘 작동합니다.
0% 피어는 다른 피어가 거의/없는 한 조각을 얻게 되며 다른 피어가 해당 조각을 가지고 있다고 보고할 때까지 0% 피어는 더 이상 업로드를 받지 않을 것입니다.

이 페이지 를 읽고 슈퍼 시드 모드가 어떻게 작동하는지 이해했습니다.

하지만 저는 초기 파종기가 아니라 모든 피어가 쉽게 조각을 얻을 수 있으므로 도움이 되지 않는다고 생각합니다.

슈퍼 시딩은 초기 시더가 될 필요가 없으며 더 적은 중복 업로드로 더 효율적으로 작동합니다. 그러나 XunLei 클라이언트에 여러 조각을 업로드하는 것보다 1시간 간격으로 동일한 조각을 여러 피어에 업로드하는 데는 그다지 신경을 쓰지 않을 것입니다.

ur 스냅샷에 있는 두 xunlei 클라이언트의 진행률이 0%입니다. 어떻게 다른 사람에게 업로드할 수 있습니까?농담?
그것은 9102이었고, 어떤 사람들은 Xunlei가 그것을 다른 클라이언트에 업로드하지 않을 것이라고 말합니다...

ur 스냅샷에 있는 두 xunlei 클라이언트의 진행률이 0%입니다. 어떻게 다른 사람에게 업로드할 수 있습니까?농담?
그것은 9102이었고, 어떤 사람들은 Xunlei가 그것을 다른 클라이언트에 업로드하지 않을 것이라고 말합니다...

XL0012의 Xunlei 클라이언트에서 볼 수 있듯이, 얼마나 많이 업로드하든 상관없이 보고되는 진행률은 항상 0%이며 어떤 정보도 업로드하지 않습니다.

내 말을 못 믿겠다면 공개 네트워크로 이동하여 무작위로 몇 개의 시드를 다운로드하십시오.

Thunder의 일부 버전(UA는 Thunder의 버전 번호이며 XL0012가 아님)이 업로드됩니다.

9102 이후에도 Xunlei가 저지른 사악한 일은 사라지지 않을 것입니다!

"UR 스냅샷에 있는 두 xunlei 클라이언트의 진행률이 0%입니다. 어떻게 다른 사람에게 업로드할 수 있습니까?"

그들은 씨앗과 동료가 그들에게 많은 조각을 업로드한 후에도 항상 0%라고 주장하면서 완료율에 대해 거짓말을 합니다.

이전 버전의 qBitTorrent(약 3.0.10 또는 그 이전?)는 부분적으로 버그 및/또는 프로그래밍 감독으로 인해 동일한 작업을 덜 수행했습니다.

Strict Super Seeding을 활성화하고 Upload Choking Algorithm을 Anti-leech로 설정했습니다. 그러나 Xunlei 클라이언트는 인기 있는 급류의 피크 시간에 연결로 무리를 범람하는 것 같습니다. 다운로드 및 업로드 속도를 높이는 유일한 솔루션은 연결 시 클라이언트 레이블이 "-XL0012..."인 IP를 수동으로 금지하는 것이었습니다. 이는 매우 힘든 작업이었습니다.

kushnarula, 이 문제 스레드의 앞부분에서 이미 지적했듯이 Anti-leech는 문제를 개선하는 대신 악화시킵니다.
또한 일반 슈퍼 시딩은 거머리 공격에 약간 저항하고 적대적인 동료를 상대하는 데 엄격한 슈퍼 시딩보다 더 효과적입니다.

적대적인 동료를 다루는 보다 포괄적인 방식이 필요합니다. 적대적인 클라이언트를 금지하는 것은 불행히도 자동화/자동화되어야 하지만 로직의 버그 가능성으로 인해 이를 비활성화할 수 있는 수단이 있어야 합니다.

용서 해줘. 내가 잘못 이해했다. 그러나 시행착오를 거쳐 결론에 도달했습니다. 또한 이것은 토렌트별 분산 합의 접근 방식 밖에서는 공정하게 해결되지 않을 것 같습니다.

2019년 4월 24일 18시 46분,

kushnarula, 이 문제 스레드의 앞부분에서 이미 지적했듯이 Anti-leech는 문제를 개선하는 대신 악화시킵니다.
또한 일반 슈퍼 시딩은 거머리 공격에 약간 저항하고 적대적인 동료를 상대하는 데 엄격한 슈퍼 시딩보다 더 효과적입니다.

적대적인 동료를 다루는 보다 포괄적인 방식이 필요합니다. 적대적인 클라이언트를 금지하는 것은 불행히도 자동화/자동화되어야 하지만 로직의 버그 가능성으로 인해 이를 비활성화할 수 있는 수단이 있어야 합니다.

—
당신이 댓글을 달았기 때문에 이것을 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub(https://github.com/qbittorrent/qBittorrent/issues/10258#issuecomment-486455764)에서 확인하거나 스레드를 음소거(https://github.com/notifications/unsubscribe-auth)하세요. /AAAQWM7YZNFLNGHCQWTNR7TPSDPOBANCNFSM4GUKOVLQ).

여기에서도 마찬가지로 공개 토렌트를 다운로드할 때 수동으로 -XL012를 금지하는 것은 제3자 추적기가 추가되지 않은 경우 dht pex를 통해 계속 팝업되기 때문에 힘든 작업입니다(일부 인기 있는 추적기는 중국에서 차단되거나 중국 IP를 차단함). 그것들은 0%로 보일 뿐만 아니라 선택하지 않은 채로 두면 업로드 대역폭의 큰 부분을 차지할 뿐만 아니라 아무런 대가도 제공하지 않습니다. 중국에 있지 않은 사용자에게는 문제가 덜하지만 GFW는 인바운드 트래픽을 아웃바운드보다 훨씬 더 많이 필터링하므로 Xunlei가 효율적으로 거머리할 수 없습니다.
(하지만 내가 아는 한 libtorrent에서 구현하지 않는 한 qb에는 이 기능이 없습니다.)

당신이 맞습니다. libtorrent의 repo에 게시해야합니까?

发送自 Windows 10 版邮件应用

发件人: NAVrasZ
发送时间: 2019年5月13日 18:10
收件人: qbittorrent/qBittorrent
抄送: MR; 작가
主题: Re: [qbittorrent/qBittorrent] 특정 클라이언트(Thunder)를 차단하는 방법이 있습니까? (#10258)

여기에서도 마찬가지로 공개 토렌트를 다운로드할 때 수동으로 -XL012를 금지하는 것은 힘든 일입니다. 0%로 보일 뿐만 아니라 선택하지 않으면 일반적으로 업로드 대역폭의 큰 부분을 차지하므로 다른 사용자에게는 거의 남기지 않고 아무 대가도 제공하지 않습니다.
(하지만 내가 아는 한 libtorrent에서 구현하지 않는 한 qb에는 이 기능이 없습니다.)
—
스레드를 작성했기 때문에 이 메시지를 받는 것입니다.
이 이메일에 직접 답장하거나 GitHub에서 보거나 스레드를 음소거하세요.

https://github.com/arvidn/libtorrent/pull/3833 에서 이미 참조했으며, 이에 대한 그들의 견해는 추가 금지 기능을 추가하는 대신 남용되고 있는 허점을 수정하는 것입니다.

블랙리스트에 추가하는 것이 Xunlei를 차단하는 빠른 방법일까요? 해당 블랙리스트에 XL0012 를 추가하기

ur 스냅샷에 있는 두 xunlei 클라이언트의 진행률이 0%입니다. 어떻게 다른 사람에게 업로드할 수 있습니까?농담?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

저는 4년 동안 qbit를 사용해 왔습니다.
그리고 Thunder 업로드(xunlei/XL002)를 본 적이 없습니다.
1GB를 올려도 진행률은 0%,
속도 버전(7.xxx)만 50kb 이하의 속도로 업로드됩니다.
Thunder 사용자가 너무 많아 항혈 기능이 필요합니다.
그냥 공식 버전을 사용하고 싶습니다.

"거머리 방지 시딩 알고리즘의 부정직한 피어 질식"이 libtorrent 1.2.1에서 구현되었으며 현재 libtorrent 1.2.2가 출시된 qbittorrent 4.2.0RC가 있습니다. Thunder(XunLei)에 문제가 있는 사용자는 테스트할 수 있습니까? 여전히 업로드가 진행되고 있다면 신고하시나요??

"거머리 방지 시딩 알고리즘의 부정직한 피어 질식"이 libtorrent 1.2.1에서 구현되었으며 현재 libtorrent 1.2.2가 출시된 qbittorrent 4.2.0RC가 있습니다. Thunder(XunLei)에 문제가 있는 사용자는 테스트할 수 있습니까? 여전히 업로드가 진행되고 있다면 신고하시나요??

https://imgur.com/qYKQqfr
아직 업로드 중

@cannotbeblank 안티 거머리 알고리즘을 사용하고

@cannotbeblank 안티 거머리 알고리즘을 사용하고

이 기능을 사용해야 합니까? 기본적으로 차단되어 있는 줄 알았습니다.
지금 알고리즘을 사용하고 있습니다.
하지만 여전히
https://imgur.com/ME9peky

거머리 방지는 효과가 없을 뿐만 아니라 이름이 의미하는 것과 반대입니다. 이 스레드의 앞부분에서 설명했듯이.

qBitTorrent의 슈퍼 시딩 방법(엄격한 슈퍼 시딩 또는 초기 시딩은 아님)이 더 효과적이지만 토렌트당 업로드 슬롯이 해당 토렌트의 피어보다 적은 경우에만 가능합니다.

"거머리 방지 시딩 알고리즘의 부정직한 피어 질식"이 libtorrent 1.2.1에서 구현되었으며 현재 libtorrent 1.2.2가 출시된 qbittorrent 4.2.0RC가 있습니다. Thunder(XunLei)에 문제가 있는 사용자는 테스트할 수 있습니까? 여전히 업로드가 진행되고 있다면 신고하시나요??

솔루션이 작동하지 않는 것 같습니다.

거머리 방지 알고리즘. Windows 10. qBittorren 4.2.0RC

현재 클라이언트에 이미 800KiB 이상을 업로드했습니다.

편집 - 후속 조치

클라이언트는 1MiB를 다운로드했으며 여전히 0.0% 진행률을 표시합니다. 무리에서 64 KiB를 다운로드한 다른 클라이언트는 진행률 열에 0.1%를 표시합니다.

편집/2

재부팅 후 현재 무리에서 XunLei의 흔적이 없습니다.

편집/3

XunLei 0012 및 0.0.1.8이 여전히 존재, 여전히 다운로드 중, 여전히 0% 진행률 표시

Linux 및 버전 4.3.0alpha1을 사용하여 여전히 연결하고 거머리만 사용합니다. 그러나 실제로 0% 이상의 완성도를 보여준 이상한 사람이 한 명 있었습니다.

PR arvidn/libtorrent#3833이 도움이 되지 않는 것 같습니다.

qbittorrent 버전: 4.2.0

업로드 질식 알고리즘이 "Anti-leech"로 설정되었습니다. (그리고 다른 두 알고리즘도 도움이 되지 않습니다.)

보시다시피 120MB(현재 금지 전 180MB) 이상을 받았는데, 이는 전체 토렌트의 1.5%와 30개를 의미합니다.

또한 스크린샷에서 UA가 7.10.34.360 인 피어를 볼 수 있습니다. 정직한 Xunlei의 이전 버전입니다.

토렌트가 들어오는 연결로 완전히 넘쳐나거나 그 중 대부분이 거머리이거나 더 나쁘다면 들어오는 연결(포트 포워딩 제거/방화벽 규칙 추가), DHT 및 PEX를 일시적으로 비활성화하십시오.
...토렌트당 최대 연결 수를 현재 연결된 피어+시드 수와 같거나 그 이하로 줄입니다. (이는 들어오는 연결을 비활성화하는 것과 동일한 효과를 나타내지만 더 많은 대역폭이 필요할 수 있습니다.)

wikipedia에 따르면 Thunder는 uTP를 지원하지 않습니다 ...또는 지원한다면 qBitTorrent/libTorrent보다 훨씬 더 열악합니다! 따라서 TCP 시드+피어 연결을 비활성화하면 완전히 차단해야 합니다.
들어오는 TCP 연결을 허용하지 않더라도(예를 들어 라우터의 포트 전달 UDP만) 이러한 연결은 거의 볼 수 없습니다. 중국의 만리장성(Great Firewall)이 중국의 Thunder 클라이언트에 연결하려는 대부분의 중국 외부 시도를 차단하기 때문입니다.

토렌트가 들어오는 연결로 완전히 넘쳐나거나 그 중 대부분이 거머리이거나 더 나쁘다면 들어오는 연결(포트 포워딩 제거/방화벽 규칙 추가), DHT 및 PEX를 일시적으로 비활성화하십시오.
...토렌트당 최대 연결 수를 현재 연결된 피어+시드 수와 같거나 그 이하로 줄입니다. (이는 들어오는 연결을 비활성화하는 것과 동일한 효과를 나타내지만 더 많은 대역폭이 필요할 수 있습니다.)

wikipedia에 따르면 Thunder는 uTP를 지원하지 않습니다 ...또는 지원한다면 qBitTorrent/libTorrent보다 훨씬 더 열악합니다! 따라서 TCP 시드+피어 연결을 비활성화하면 완전히 차단해야 합니다.
들어오는 TCP 연결을 허용하지 않더라도(예를 들어 라우터의 포트 전달 UDP만) 이러한 연결은 거의 볼 수 없습니다. 중국의 만리장성(Great Firewall)이 중국의 Thunder 클라이언트에 연결하려는 대부분의 중국 외부 시도를 차단하기 때문입니다.

ㅋ ㅋ ㅋ
이전 댓글 이미지 봤어...........?
썬더는 오래전부터 uTP를 지원하고,,,,,

좋은 지적입니다 ... 예, 나는 그것을 놓쳤습니다. 그러나 uTP로 STUN을 할 수 있습니까?
... 그렇지 않은 경우 UDP를 전달하지 마십시오. 그러면 들어오는 연결이 안될 수 있습니다.

웹 API 및 ipfilter.dat(예 : 토렌트 피어 데이터 가져오기 및 애플리케이션 기본 설정 설정 )의 도움으로 이러한 특정 피어 클라이언트(예: XL0012, Xunlei, 클라이언트: 7.2)는 빌드되지는 않았지만 여전히 쉽게 필터링할 수 있습니다. - 인 기능.

BTW, 고정 IP가 없는 클라이언트를 고려하면 IP 필터링의 시간 기반 회전 메커니즘을 구현해야 할 수 있습니다.

나는 모든 사람들이 특정 클라이언트를 금지하려고 할 때 클라이언트를 코딩하는 사람들이 클라이언트 ID를 실제가 아닌 다른 것으로 스푸핑할 수 있도록 만들거나 활성화할 수 있다는 사실에 대해 생각했다고 가정합니다. 따라서 이것은 실제로 좋지 않습니다. 반드시 '고치다'? 아니면 제가 틀렸으면 좋겠습니다. 저는 코딩을 많이 하지 않습니다.

말하기 싫지만 드롭다운 메뉴와 같이 특정 국가의 연결을 우선시하고 그 위에 전송 속도를 기반으로 전송 속도를 설정할 수 있습니까? 그러나 이것은 아마도 qBitorrent 문제를 넘어섰을 것입니까? 저도 이 문제에 대해 처음으로 생각하는 사람이 아닐 거라 확신합니다. 죄송합니다.

웹 API 및 ipfilter.dat(예: Get torrent peers data 및 Set application Preferences )의 도움으로 이러한 특정 피어 클라이언트(예: XL0012, Xunlei, client: 7.2.)는 빌드되지는 않았지만 여전히 쉽게 필터링할 수 있습니다. - 인 기능.

BTW, 고정 IP가 없는 클라이언트를 고려하면 IP 필터링의 시간 기반 회전 메커니즘을 구현해야 할 수 있습니다.
스크립트의 지연 버전을 얻을 수 있습니까?
xl0012만 금지하면 타사 qtorrent는 모든 Thunder를 금지합니다.

말하기 싫지만 드롭다운 메뉴와 같이 특정 국가의 연결을 우선시하고 그 위에 전송 속도를 기반으로 전송 속도를 설정할 수 있습니까? 그러나 이것은 아마도 qBitorrent 문제를 넘어섰을 것입니까?

qBitTorrent(또는 qBT가 사용하는 libtorrent)에는 "로컬"로 결정되는 IP에 더 높은 우선 순위 또는 무제한 속도를 제공하는 로컬 피어 처리가 있습니다. 이러한 동작은 낮은 핑 시간 및/또는 경로 추적 홉 수를 가진 중간 거리 피어로 확장될 수 있으며 멀리 떨어져 있는 피어는 우선 순위가 낮습니다.
이 동작은 모든 사람이 필요로 하지 않고 기본적으로 켜짐으로 설정하면 Thunder 피어가 많지 않은 토렌트 떼에 해로울 수 있으므로 기본적으로 OFF로 설정해야 합니다.

Linux 사용자는 임시 해결 방법으로 이러한 악성 클라이언트의 패킷을 필터링하도록 방화벽을 구성할 수 있습니다.

예를 들어:
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

대부분의 경우 이것이 작동하지만 때로는 일부 XL0012 클라이언트가 연결된 것을 볼 수 있습니다. 그들이 어떤 종류의 난독화를 하고 있는지 잘 모르겠습니다.

#issuecomment-462029063 에서 누군가가 말합니다.

ur 스냅샷에 있는 두 xunlei 클라이언트의 진행률이 0%입니다. 어떻게 다른 사람에게 업로드할 수 있습니까?농담?
都９１０２年了，还有人在说迅雷不上传给其他客户端...

번역:

지금은 2019년이고 여전히 XunLei(Thunder)가 다른 클라이언트에 업로드하지 않을 것이라고 말하는 사람들이 있습니다.

都 0202 年了

그러나 지금은 2020년이기도 하고 이것이 내가 본 것입니다.

(영원히 0% 피어)

네, 썬더는 그렇게 사악하지 않은 새 버전을 출시했지만 여전히 이전 버전의 사악한 클라이언트를 사용하는 사람들이 많이 있습니다. 따라서 거머리 방지 및 클라이언트 차단 기능이 여전히 필요합니다.

업데이트: 영어 번역 추가

Xunlei가 업로드하지 않는 클라이언트에 대해 매우 효과적인 bitcomet으로 전환하십시오.작가는 국내출처 특유의 천둥 문제를 푸는데 시간을 들이지 않을 것 같다.

@Phuker @foxdodo 영어만 부탁드립니다.

저도 이 문제를 보고 있습니다. "-XL0012" 문자열이 있는 클라이언트가 리칭되고 진행 상황이 진행되지 않습니다. 범위 밖일 수도 있지만 해당 클라이언트를 차단하는 기능이 있으면 좋을 것입니다.

스냅샷에 있는 두 Thunder 클라이언트의 단계는 0%입니다. 어떻게 다른 사람에게 업로드할 수 있습니까? [9102],...

저는 4년 동안 큐빗을 사용해 왔으며,
Thunder 업로드(Xunlei/XL002)를 본 적이 없습니다.
1GB를 올려도 진행률은 0%이고, 50kb 이하의 속도로는 스피드 버전(7.xx x)만 업로드 됩니다.
Thunder 사용자가 너무 많아서 항혈 기능이 필요합니다.
그냥 공식 버전을 사용하고 싶습니다.

pt를 사용하여 토렌트를 다운로드하는 동안 pt 웹 사이트 밴드는 천둥(XL0012) 금지에 작동하는 qbittorrent 강화 버전을 사용하지만 공식 버전을 사용하면 그렇지 않습니다.