Tracker Information

From Depthstrike Entertainment
Revision as of 00:52, 4 June 2012 by DreadWingKnight (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

General information

  • The EAD tracker network consists of four specially configured load-balancing trackers with multiple listen ports. (Reference Layout)
  • 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:

  • Azureus 2.3.x.x and older - Outdated versions, frequent hacked clients.
  • Azureus - Encryption related bugs fixed in
  • 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. Details
  • Transmission - All Versions - Abusive Announcing. Details
    • (Due to the attitude I received in reporting the issue with the announce interval, this ban is permanent)
  • TorrenTopia - All Versions - Does not support key or compact.
  • qBitTorrent - All Versions - Abusive Announcing.
  • Xunelei - All Versions - Abusive Announcing, poor sharing code, poor announce rewriting, stupid proxy-attempt behavior, poor protocol implementation. Note: Because of the flaws in this client's code, you may find your IP or your entire internet provider completely unable to visit our site.

Permitted/Working Clients

Permitted Clients

  • BitTornado 0.1.x and up Excluding 0.3.0 and 0.3.1
  • ABC 2.6.9 and up
  • Azureus and up
  • Shareaza and up
  • µTorrent 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 random port selector script (Mirror) 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: id20:A310--000oPlMo6GM3ca4:porti4030ee
    • 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 (reference Document)
    • 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 stronly 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 Multiscrape 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. (Paramater Parser)

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.

Hosted Groups

Back To Main - Depthstrike Home