P2P:Protocol:Specifications:AbuseDetection

From Depthstrike Entertainment
Jump to: navigation, search

Announce Abuse Detection Protocol

  • This is a Tracker-side protocol for detecting abusive announces from poorly written clients and swarm poisoner groups.
  • The intention is to reduce the extra load generated by clients that announce too frequently.

Considerations

  • Announce Intervals exist for a reason. A client that is disrespecting the announce interval should NOT be permitted to access the tracker.
  • Some heavily-nat'd areas may generate high numbers of users using the same IP.
  • Anti-P2P groups may sometimes flood trackers with large numbers of peers with different peer IDs and ports but all from the same IP.
  • Lower announce intervals (below 900s) don't permit proper checking of abuse.

Test Implementation Database Format

  • The test implementation of this restriction uses an extension to the BEncoded dstate file.
  • Extension Format:
abuselog - Dictionary
\«IP Address» - Dictionary
 |lastannounce = «Timestamp of last announce, abusive or not» - Number
 |lastinfohash = «last infohash announced» - String
 |totalabuses = «number of abusive announces since last nonabusive announce» - Number
 \abusesbyhash - Dictionary
  \«infohash of abusive announce» - Dictionary
   |lastannounce = «timestamp of last announce, abusive or not» - Number
   \totalabuses = «number of abusive announces since last nonabusive announce» - Number

Test Implementation Announce Handling Procedures

  • The test implementation of this restriction is CBTT
  • The abuse check doesn't start until the first announce that is less than the minimum interval specified in the configuration.
  • The first and second violations on a torrent automatically forces numwant to be 0, overriding the client's numwant value.
  • Subsequent violations result in rejection from the tracker.
    • Beyond a set number of violations on a torrent (5 by default) or globally (10 by default), the rejection length becomes the announce interval multiplied by the number of violations. For example, if a source IP has hammered with 40 requests, they will be banned for 40 announce cycles. Each subsequent request will add another announce cycle to the ban.
  • These bans are retained across tracker sessions.