Deadfire
Wed, 11-22-2006, 10:20 PM
Reading the content of this post will answer most questions asked about the tracker in this forum, so reading of it is strongly recommended
Note that Gotwoot is part of the EAD tracker network. More information is available on the DepthStrike Wiki (http://wiki.depthstrike.com/index.php/Tracker_Information) and Copy+ Pasted below. Please note those cilents that are banned
General information
The EAD tracker network consists of four specially configured load-balancing trackers with multiple listen ports.
These trackers share peer data with each other. Configuring your client to use the backup layout instead of the load balancing layout is not recommended as it causes an abuse scenario with the trackers.
Properly made torrents for use with the EAD network are heavily enforced on locally hosted sites.
As of September 20, 2006, there is a standing issue with hardware reliability relating to the primary router providing access to the central system. We are still working on getting this sorted (donations would be helpful)
Client Banlist
The Following Clients are currently banned from EAD's tracker network (with the reasons why):
Azureus 2.3.x.x and older - Outdated versions, frequent hacked clients.
Azureus 2.4.0.0 - Encryption related bugs fixed in 2.4.0.2
Shareaza 2.1.x.x and older - Outdated versions
Shad0w's Experimental S-5.x line - Outdated versions
BitTornado T-0.3.0 and T-0.3.1 - Webseed support bug
UPnP Modded Shad0ws Experimental - Made obsolete by BitTornado
BitComet 0.58 and older - Outdated versions
BitLord - All Versions - Poorly implemented client, built on outdated cores, spyware suspected.
Mainline 3.3 and older - Outdated Versions
BT++ - Bad history of abuse
XBT - Bad announce protocols
µTorrent 1.1.7 and older - Abusive Announcing, Poor/incomplete announce implementation.
Transmission - All Versions - Abusive Announcing.
TorrenTopia - All Versions - Does not support key or compact.
Permitted Clients
BitTornado 0.1.x and up Excluding 0.3.0 and 0.3.1
ABC 2.6.9 and up
Azureus 2.4.0.1 and up
Shareaza 2.2.0.0 and up
µTorrent 1.2.0.0 and up
BitComet 0.59 and up (Support for this has been dropped as of November 8, 2005. Don't be suprised to see it completely banned)
Mainline 4.x and up (We don't support this, it doesn't automatically failover. If this client doesn't work, you're on your own)
Port Blacklisting
Update November 1, 2005
Ports typically reserved for system services (ports below 1024) are blacklisted from this tracker network.
Traditional default p2p ports are not recommended.
This (http://torrenthelp.depthstrike.com/randomport.php) random port selector script has been developed to give ports that are not traditional defaults.
Compact Announce Requirement
Our tracker network requires that clients support the "compact" announce protocol.
This is done because of the MASSIVE bandwidth savings involved
In comparison of size, the compact announce protocol offers the greatest savings in bandwidth of the three announce protocols.
Per-peer included in response:
d2:ip15:192.168.111.1277:peer id20:A310--000oPlMo6GM3ca4:porti4030ee
d2:ip15:192.168.111.1274:porti4030ee
AAAAFF
67 bytes/peer for traditional (maximum)
46 bytes/peer for no_peer_id (maximum)
6 bytes/peer for compact (maximum and minimum)
Each announce reply has between 50 and 200 peers in it. With the difference in size, the bandwidth savings adds up.
This restriction is permanent as of this time.
Key Announce Paramater Requirement
As of October 25, 2005 we require clients support the "key" announce paramater
key: Optional. An additional identification that is not shared with any users. It is intended to allow a client to prove their identity should their IP address change.
Users on connections whose IP changes every reconnect will appreciate this change, as it allows clients to keep the tracker up to date on IP changes.
This restriction is permanent as of this time.
Clients Confirmed to not have support for this paramater:
Getright
Torrentopia
Announce Interval Policy
We have a 30 minute announce interval for a reason.
A 25 minute Minimum interval has been set and will be HARD enforced.
Hammering the tracker with requests for additional peers will NOT BE TOLERATED.
If you are using a client that forcibly overrides the announce interval and won't follow the tracker's settings, you will NOT get any more peers to connect out to.
This lock will override whatever numwant paramater your client specifies (if any) and will set it to 0.
Excessive abuses will result in an automatic rejection from the tracker and removal from swarms.
Due to problems with the code involved, this restriction has not yet been implemented.
IP addresses that abusively add hundreds of peers to a swarm will be banned from the entire network.
IP Address Specifying Policy
We have had a long standing policy that specifying public IP addresses should only be done by those hosting trackers.
If you are attempting to specify your public IP address (or an IP address that is not yours in an attempt to DDoS someone) the IP address you specify will be ignored by our tracker. We use the IP address your client connects to the tracker from.
You will still be able to download, but specifying an IP address won't work.
This restriction is permanent as of this time.
Selective Downloading Policy
Selective downloading of files within multifile torrents on Enlist-a-Distro trackers is NOT SUPPORTED.
Selectively not downloading files within a batch negatively affects piece distribution across the entire swarm.
By selectively not downloading files within a batch, you are forcing peers to get pieces of those files from other peers, putting needless strain on them.
In a choice between selectively not downloading files from the batch and resuming using files you have already, RESUME. A peer that resumes from already completed files will get and give better speeds to and from everyone.
Resuming existing files to verify the files (and re-download damaged sections) as well as to get a head-start on a batch torrent (example: having episodes 1-22 of a 24 episode batch and wanting to get 23 and 24. Resume the batch using 1-22, giving a 91% complete before the torrent is actually started, would be supported and encouraged, whereas selectively skipping 1-22 would be unsupported)
Reachability checking
We do not currently employ a reachability checker on the tracker network.
Complaints about not being able to connect to peers or seeds will be ignored, especially if your client cannot accept incoming connections.
Please ensure your client is reachable, as it greatly improves the health of the swarm to have everyone connectable.
Use of router DMZ is strongly not recommended.
Security issues prevent DMZ practicality.
Some routers cause data corruption in downloads (not restricted to torrent downloads) when their DMZ mode is active.
Other Notes
Although the Mainline BT client is permitted on the tracker network, there is no support for its use on the network because it lacks the automatic-failover support that other clients have. If you are having problems with trackers on our network and are using Mainline, our first troubleshooting step will be to recommend the use of one of our Recommended BT Clients
On November 10, 2005, our trackers started supporting including the seed/downloader totals in announce replies in an effort to reduce the use of the scrape function. If your client attempts to obtain peer count data from the tracker, make sure it attempts to obtain it from the announce reply before attempting to scrape.
Of the trackers in our network, only one permits obtaining the scrape of all torrents in a single request. All the leaf trackers (which clients normally announce to) require that one or more info_hash values be specified. All leaf trackers support which allows them to return information on multiple torrents in a single request.
All statistics pages built by EAD staff selectively obtain statistics on the specific torrents they are displaying information on.
Statistics pages built by EAD staff that obtain statistics from external trackers do so in a similar manner to the ones local to the EAD network.
Group representatives with a mix of torrents hosted on Enlist-A-Distro trackers and PHP-based trackers should encourage their tracker administrators to upgrade their tracker to allow for multiple info_hash values in a single /scrape.php request.
Outstanding issues
On linux, mainline and bittornado may get rejected as a banned version even though they are a supported version. The problem here is underlying python library issues. The underlying python libraries are overriding the client's identification, causing the banlist to trigger on them. Fixing/upgrading your python version will solve this as current versions of those libraries don't override the identification.
Note that Gotwoot is part of the EAD tracker network. More information is available on the DepthStrike Wiki (http://wiki.depthstrike.com/index.php/Tracker_Information) and Copy+ Pasted below. Please note those cilents that are banned
General information
The EAD tracker network consists of four specially configured load-balancing trackers with multiple listen ports.
These trackers share peer data with each other. Configuring your client to use the backup layout instead of the load balancing layout is not recommended as it causes an abuse scenario with the trackers.
Properly made torrents for use with the EAD network are heavily enforced on locally hosted sites.
As of September 20, 2006, there is a standing issue with hardware reliability relating to the primary router providing access to the central system. We are still working on getting this sorted (donations would be helpful)
Client Banlist
The Following Clients are currently banned from EAD's tracker network (with the reasons why):
Azureus 2.3.x.x and older - Outdated versions, frequent hacked clients.
Azureus 2.4.0.0 - Encryption related bugs fixed in 2.4.0.2
Shareaza 2.1.x.x and older - Outdated versions
Shad0w's Experimental S-5.x line - Outdated versions
BitTornado T-0.3.0 and T-0.3.1 - Webseed support bug
UPnP Modded Shad0ws Experimental - Made obsolete by BitTornado
BitComet 0.58 and older - Outdated versions
BitLord - All Versions - Poorly implemented client, built on outdated cores, spyware suspected.
Mainline 3.3 and older - Outdated Versions
BT++ - Bad history of abuse
XBT - Bad announce protocols
µTorrent 1.1.7 and older - Abusive Announcing, Poor/incomplete announce implementation.
Transmission - All Versions - Abusive Announcing.
TorrenTopia - All Versions - Does not support key or compact.
Permitted Clients
BitTornado 0.1.x and up Excluding 0.3.0 and 0.3.1
ABC 2.6.9 and up
Azureus 2.4.0.1 and up
Shareaza 2.2.0.0 and up
µTorrent 1.2.0.0 and up
BitComet 0.59 and up (Support for this has been dropped as of November 8, 2005. Don't be suprised to see it completely banned)
Mainline 4.x and up (We don't support this, it doesn't automatically failover. If this client doesn't work, you're on your own)
Port Blacklisting
Update November 1, 2005
Ports typically reserved for system services (ports below 1024) are blacklisted from this tracker network.
Traditional default p2p ports are not recommended.
This (http://torrenthelp.depthstrike.com/randomport.php) random port selector script has been developed to give ports that are not traditional defaults.
Compact Announce Requirement
Our tracker network requires that clients support the "compact" announce protocol.
This is done because of the MASSIVE bandwidth savings involved
In comparison of size, the compact announce protocol offers the greatest savings in bandwidth of the three announce protocols.
Per-peer included in response:
d2:ip15:192.168.111.1277:peer id20:A310--000oPlMo6GM3ca4:porti4030ee
d2:ip15:192.168.111.1274:porti4030ee
AAAAFF
67 bytes/peer for traditional (maximum)
46 bytes/peer for no_peer_id (maximum)
6 bytes/peer for compact (maximum and minimum)
Each announce reply has between 50 and 200 peers in it. With the difference in size, the bandwidth savings adds up.
This restriction is permanent as of this time.
Key Announce Paramater Requirement
As of October 25, 2005 we require clients support the "key" announce paramater
key: Optional. An additional identification that is not shared with any users. It is intended to allow a client to prove their identity should their IP address change.
Users on connections whose IP changes every reconnect will appreciate this change, as it allows clients to keep the tracker up to date on IP changes.
This restriction is permanent as of this time.
Clients Confirmed to not have support for this paramater:
Getright
Torrentopia
Announce Interval Policy
We have a 30 minute announce interval for a reason.
A 25 minute Minimum interval has been set and will be HARD enforced.
Hammering the tracker with requests for additional peers will NOT BE TOLERATED.
If you are using a client that forcibly overrides the announce interval and won't follow the tracker's settings, you will NOT get any more peers to connect out to.
This lock will override whatever numwant paramater your client specifies (if any) and will set it to 0.
Excessive abuses will result in an automatic rejection from the tracker and removal from swarms.
Due to problems with the code involved, this restriction has not yet been implemented.
IP addresses that abusively add hundreds of peers to a swarm will be banned from the entire network.
IP Address Specifying Policy
We have had a long standing policy that specifying public IP addresses should only be done by those hosting trackers.
If you are attempting to specify your public IP address (or an IP address that is not yours in an attempt to DDoS someone) the IP address you specify will be ignored by our tracker. We use the IP address your client connects to the tracker from.
You will still be able to download, but specifying an IP address won't work.
This restriction is permanent as of this time.
Selective Downloading Policy
Selective downloading of files within multifile torrents on Enlist-a-Distro trackers is NOT SUPPORTED.
Selectively not downloading files within a batch negatively affects piece distribution across the entire swarm.
By selectively not downloading files within a batch, you are forcing peers to get pieces of those files from other peers, putting needless strain on them.
In a choice between selectively not downloading files from the batch and resuming using files you have already, RESUME. A peer that resumes from already completed files will get and give better speeds to and from everyone.
Resuming existing files to verify the files (and re-download damaged sections) as well as to get a head-start on a batch torrent (example: having episodes 1-22 of a 24 episode batch and wanting to get 23 and 24. Resume the batch using 1-22, giving a 91% complete before the torrent is actually started, would be supported and encouraged, whereas selectively skipping 1-22 would be unsupported)
Reachability checking
We do not currently employ a reachability checker on the tracker network.
Complaints about not being able to connect to peers or seeds will be ignored, especially if your client cannot accept incoming connections.
Please ensure your client is reachable, as it greatly improves the health of the swarm to have everyone connectable.
Use of router DMZ is strongly not recommended.
Security issues prevent DMZ practicality.
Some routers cause data corruption in downloads (not restricted to torrent downloads) when their DMZ mode is active.
Other Notes
Although the Mainline BT client is permitted on the tracker network, there is no support for its use on the network because it lacks the automatic-failover support that other clients have. If you are having problems with trackers on our network and are using Mainline, our first troubleshooting step will be to recommend the use of one of our Recommended BT Clients
On November 10, 2005, our trackers started supporting including the seed/downloader totals in announce replies in an effort to reduce the use of the scrape function. If your client attempts to obtain peer count data from the tracker, make sure it attempts to obtain it from the announce reply before attempting to scrape.
Of the trackers in our network, only one permits obtaining the scrape of all torrents in a single request. All the leaf trackers (which clients normally announce to) require that one or more info_hash values be specified. All leaf trackers support which allows them to return information on multiple torrents in a single request.
All statistics pages built by EAD staff selectively obtain statistics on the specific torrents they are displaying information on.
Statistics pages built by EAD staff that obtain statistics from external trackers do so in a similar manner to the ones local to the EAD network.
Group representatives with a mix of torrents hosted on Enlist-A-Distro trackers and PHP-based trackers should encourage their tracker administrators to upgrade their tracker to allow for multiple info_hash values in a single /scrape.php request.
Outstanding issues
On linux, mainline and bittornado may get rejected as a banned version even though they are a supported version. The problem here is underlying python library issues. The underlying python libraries are overriding the client's identification, causing the banlist to trigger on them. Fixing/upgrading your python version will solve this as current versions of those libraries don't override the identification.