Yes, those settings increase overheads on any BT client. (Though some more than others...)
Doing all of those at their worst can make overheads resemble a 5 ton mail truck delivering a single postcard.
Anti Leech System
-
ciaobaby
Re: Anti Leech System
Nope. Protocol overhead is the same no matter what the client is.(Though some more than others...)
-
Switeck
Re: Anti Leech System
Protocol overhead may be the same number of bytes on a per-packet basis, but if some clients are using larger or smaller uTP packet sizes the percent overhead can change greatly.
Announcing to every tracker on every tier of every torrent once every 30 mins regardless of tracker recommendations, increases overheads slightly for the client and greatly for the trackers. This is exactly why openbittorrent and publicbt.com public trackers shut down in protest.
If a BT client tries to connect/reconnect to peers/seeds once every 30 seconds instead of once per minute and lacks a cool-down after many failures on that ip, this increases overheads especially if they are using high half open limits and have multiple busy torrent running. Or they could lack a per-ip cool-down and retry an ip as fast as half open allows, which can result in 4+ retries per second if only 1 torrent is running.
HAVE messages are sent to all connected peers/seeds for each completed piece a peer gets, though some BT clients don't do this (at least under some circumstances) despite it being part of the protocol. This supposedly "eats up" >10% of all bandwidth of big swarms. HAVE ALL and HAVE NONE are not implemented or improperly used. FAST HAVEs (IE: recommended piece feature) is an important part of the BitTorrent protocol that basically no BT client does anything with if they implement it at all.
Some are simply far more aggressive on "endgame" strategies, even resorting to using them all the time. It can result in extremely high overheads and wasted traffic.
Announcing to every tracker on every tier of every torrent once every 30 mins regardless of tracker recommendations, increases overheads slightly for the client and greatly for the trackers. This is exactly why openbittorrent and publicbt.com public trackers shut down in protest.
If a BT client tries to connect/reconnect to peers/seeds once every 30 seconds instead of once per minute and lacks a cool-down after many failures on that ip, this increases overheads especially if they are using high half open limits and have multiple busy torrent running. Or they could lack a per-ip cool-down and retry an ip as fast as half open allows, which can result in 4+ retries per second if only 1 torrent is running.
HAVE messages are sent to all connected peers/seeds for each completed piece a peer gets, though some BT clients don't do this (at least under some circumstances) despite it being part of the protocol. This supposedly "eats up" >10% of all bandwidth of big swarms. HAVE ALL and HAVE NONE are not implemented or improperly used. FAST HAVEs (IE: recommended piece feature) is an important part of the BitTorrent protocol that basically no BT client does anything with if they implement it at all.
Some are simply far more aggressive on "endgame" strategies, even resorting to using them all the time. It can result in extremely high overheads and wasted traffic.
-
ciaobaby
Re: Anti Leech System
There is little or no transport overhead with uTP as it is based on UDP which has no parity or error checking on the incoming packets, and yes of course poorly configured (or poorly implemented) clients are going to exacerbate overhead 'issues', but if it configuration, 'tweak' it, if it is implementation, use a different client. Nobody is forced into using any particular client and there is no shortage of choice.
-
sledgehammer_999
- Administrator
- Posts: 2443
- Joined: Sun Jan 23, 2011 1:17 pm
Re: Anti Leech System
[quote="Switeck"]
Protocol overhead may be the same number of bytes on a per-packet basis, but if some clients are using larger or smaller uTP packet sizes the percent overhead can change greatly.
Announcing to every tracker on every tier of every torrent once every 30 mins regardless of tracker recommendations, increases overheads slightly for the client and greatly for the trackers. This is exactly why openbittorrent and publicbt.com public trackers shut down in protest.
If a BT client tries to connect/reconnect to peers/seeds once every 30 seconds instead of once per minute and lacks a cool-down after many failures on that ip, this increases overheads especially if they are using high half open limits and have multiple busy torrent running. Or they could lack a per-ip cool-down and retry an ip as fast as half open allows, which can result in 4+ retries per second if only 1 torrent is running.
HAVE messages are sent to all connected peers/seeds for each completed piece a peer gets, though some BT clients don't do this (at least under some circumstances) despite it being part of the protocol. This supposedly "eats up" >10% of all bandwidth of big swarms. HAVE ALL and HAVE NONE are not implemented or improperly used. FAST HAVEs (IE: recommended piece feature) is an important part of the BitTorrent protocol that basically no BT client does anything with if they implement it at all.
Some are simply far more aggressive on "endgame" strategies, even resorting to using them all the time. It can result in extremely high overheads and wasted traffic.
[/quote]
And I think this is part of the reason why the qbt author (and not me) didn't expose every little low-level configuration option and it left it upon libtorrent to choose something sane. Many users would misconfigure the client and cause havoc. The few experienced ones are an exception not big enough to warrant exposing those options.
Protocol overhead may be the same number of bytes on a per-packet basis, but if some clients are using larger or smaller uTP packet sizes the percent overhead can change greatly.
Announcing to every tracker on every tier of every torrent once every 30 mins regardless of tracker recommendations, increases overheads slightly for the client and greatly for the trackers. This is exactly why openbittorrent and publicbt.com public trackers shut down in protest.
If a BT client tries to connect/reconnect to peers/seeds once every 30 seconds instead of once per minute and lacks a cool-down after many failures on that ip, this increases overheads especially if they are using high half open limits and have multiple busy torrent running. Or they could lack a per-ip cool-down and retry an ip as fast as half open allows, which can result in 4+ retries per second if only 1 torrent is running.
HAVE messages are sent to all connected peers/seeds for each completed piece a peer gets, though some BT clients don't do this (at least under some circumstances) despite it being part of the protocol. This supposedly "eats up" >10% of all bandwidth of big swarms. HAVE ALL and HAVE NONE are not implemented or improperly used. FAST HAVEs (IE: recommended piece feature) is an important part of the BitTorrent protocol that basically no BT client does anything with if they implement it at all.
Some are simply far more aggressive on "endgame" strategies, even resorting to using them all the time. It can result in extremely high overheads and wasted traffic.
[/quote]
And I think this is part of the reason why the qbt author (and not me) didn't expose every little low-level configuration option and it left it upon libtorrent to choose something sane. Many users would misconfigure the client and cause havoc. The few experienced ones are an exception not big enough to warrant exposing those options.