BEP: XXX
Title: Minor Extensions to the BitTorrent DHT
Version: $Revision$
Last-Modified: $Date$
Author: Juliusz Chroboczek
Status: Draft
Type: Standards Track
Requires: 5
Content-Type: text/x-rst
Created: 1-Jan-2010
Post-History: 6-Jan-2010: change "drop" to be a string, split notes about status
This document defines a number of minor extensions to the BitTorrent DHT protocol [1]. These extensions are designed to be independent but compatible with the IPv6 extensions to the DHT [2].
Note: the extension defined in this section has been widely implemented, and is safe to deploy.
BEP-5 specifies that the reply to a get_peers request as containing either a "nodes" or a "values" key, but not both. This document revises this by specifying that the reply to a get_peers request should always contain a "nodes" key, independently of whether a "values" key is included or not. The logic for including a "values" key is unchanged: it is included if the replying node has any stored values for the requested key.
This is an incompatible change to BEP-5; however, it has been widely deployed for over one year, with no negative consequences.
Note that BEP-32 further refines the semantics of get_peers (and find_nodes) when the request contains a "want" key.
To do: explain what widening is.
BEP-5 doesn't define any way for a node to signal the fact that it is being overloaded, either because it is tracking too many torrents for its limited storage space, or because it is receiving more requests than it is willing to reply to.
To do: make it clearer that the two forms of overload are orthogonal.
Note: the extension defined in this section has been implemented, albeit not widely, and is believed to be safe to deploy.
Upon receiving a get_peers request, a node that doesn't have any space for storing further values should indicate this fact by omitting the "token" parameter from the reply to the get_peers request. A node receiving a reply to get_peers with no "token" parameter should not send an announce_peers request, and may optionally perform widening.
Note: The extension defined in this section is still under discussion, and not suitable for deployment yet.
The toplevel dictionary of any reply may include a "drop" parameter, the value of which is one of the strings "overload" and "bootstrap".
A "drop" parameter with value "overload" indicates that the replying node is overloaded, and requests that it be dropped from the requesting node's routing table. A node receiving a reply with "drop" set to "overload" should drop the replying node from its routing table if that can be done without endangering the integrity of the DHT, i.e. if it doesn't belong to the same bucket as the receiving node.
A "drop" parameter with value "bootstrap" indicates that the replying node is purely a bootstrap node, and should not be included in any routing tables. A node receiving a reply with "drop" set to "bootstrap" should unconditionally drop the replying node from its routing table, even if it belongs to the same bucket as the receiving node.
Values of the "drop" parameter other than "overload" and "bootstrap" are reserved for further extensions, and must be treated on reception as equivalent to the absence of a "drop" parameter.
In order to prevent an easy denial-of-service attack, a node must ignore a "drop" parameter included in a request.
Most of the ideas in this document are not my own, but have been gathered in discussions in various public forums. I specifically acknowledge the influence of The 8472, Arvid Norberg and Greg Hazel.
| [1] | BEP_0005. DHT Protocol. (http://www.bittorrent.org/beps/bep_0005.html) |
| [2] | BEP_0032. BitTorrent DHT Extensions for IPv6. (http://www.bittorrent.org/beps/bep_0032.html) |
This document has been placed in the public domain.