| 1 | <?xml version="1.0" encoding="utf-8" ?> |
|---|
| 2 | <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> |
|---|
| 3 | <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> |
|---|
| 4 | <head> |
|---|
| 5 | <meta http-equiv="Content-Type" content="text/html; charset=utf-8" /> |
|---|
| 6 | <meta name="generator" content="Docutils 0.5: http://docutils.sourceforge.net/" /> |
|---|
| 7 | <title></title> |
|---|
| 8 | <link rel="stylesheet" href="../css/bep.css" type="text/css" /> |
|---|
| 9 | </head> |
|---|
| 10 | <body> |
|---|
| 11 | <div class="document"> |
|---|
| 12 | |
|---|
| 13 | <div id="upper" class="clear"> |
|---|
| 14 | <div id="wrap"> |
|---|
| 15 | <div id="header"> |
|---|
| 16 | <h1><a href="../index.html">BitTorrent<span>.org</span></a></h1> |
|---|
| 17 | </div> |
|---|
| 18 | <div id="nav"> |
|---|
| 19 | <ul> |
|---|
| 20 | <li><a href="../index.html">Home</a></li> |
|---|
| 21 | <li><a href="../introduction.html">For Users</a></li> |
|---|
| 22 | <li><span>For Developers</span></li> |
|---|
| 23 | <!-- <li><a href="./blog">Blog</a></li> --> |
|---|
| 24 | <li><a href="../donate.html">Donate!</a></li> |
|---|
| 25 | </ul> |
|---|
| 26 | </div> <!-- nav --> |
|---|
| 27 | <!-- ### Begin Content ### --> |
|---|
| 28 | <div id="second"> |
|---|
| 29 | |
|---|
| 30 | |
|---|
| 31 | |
|---|
| 32 | <table class="rfc2822 docutils field-list" frame="void" rules="none"> |
|---|
| 33 | <col class="field-name" /> |
|---|
| 34 | <col class="field-body" /> |
|---|
| 35 | <tbody valign="top"> |
|---|
| 36 | <tr class="field"><th class="field-name">BEP:</th><td class="field-body">5</td> |
|---|
| 37 | </tr> |
|---|
| 38 | <tr class="field"><th class="field-name">Title:</th><td class="field-body">DHT Protocol</td> |
|---|
| 39 | </tr> |
|---|
| 40 | <tr class="field"><th class="field-name">Version:</th><td class="field-body">10528</td> |
|---|
| 41 | </tr> |
|---|
| 42 | <tr class="field"><th class="field-name">Last-Modified:</th><td class="field-body"><a class="reference external" href="https://svn.bittorrent.com/trac.cgi/browser/dotorg/trunk/html/beps/bep_0005.rst">2008-02-04 16:10:30 -0800 (Mon, 04 Feb 2008)</a></td> |
|---|
| 43 | </tr> |
|---|
| 44 | <tr class="field"><th class="field-name">Author:</th><td class="field-body">Andrew Loewenstern <drue at bittorrent.com></td> |
|---|
| 45 | </tr> |
|---|
| 46 | <tr class="field"><th class="field-name">Status:</th><td class="field-body">Draft</td> |
|---|
| 47 | </tr> |
|---|
| 48 | <tr class="field"><th class="field-name">Type:</th><td class="field-body">Standards Track</td> |
|---|
| 49 | </tr> |
|---|
| 50 | <tr class="field"><th class="field-name">Created:</th><td class="field-body">31-Jan-2008</td> |
|---|
| 51 | </tr> |
|---|
| 52 | <tr class="field"><th class="field-name">Post-History:</th><td class="field-body"></td> |
|---|
| 53 | </tr> |
|---|
| 54 | </tbody> |
|---|
| 55 | </table> |
|---|
| 56 | <hr /> |
|---|
| 57 | <div class="contents topic" id="contents"> |
|---|
| 58 | <p class="topic-title first">Contents</p> |
|---|
| 59 | <ul class="simple"> |
|---|
| 60 | <li><a class="reference internal" href="#overview" id="id3">Overview</a></li> |
|---|
| 61 | <li><a class="reference internal" href="#routing-table" id="id4">Routing Table</a></li> |
|---|
| 62 | <li><a class="reference internal" href="#bittorrent-protocol-extension" id="id5">BitTorrent Protocol Extension</a></li> |
|---|
| 63 | <li><a class="reference internal" href="#torrent-file-extensions" id="id6">Torrent File Extensions</a></li> |
|---|
| 64 | <li><a class="reference internal" href="#krpc-protocol" id="id7">KRPC Protocol</a><ul> |
|---|
| 65 | <li><a class="reference internal" href="#contact-encoding" id="id8">Contact Encoding</a></li> |
|---|
| 66 | <li><a class="reference internal" href="#queries" id="id9">Queries</a></li> |
|---|
| 67 | <li><a class="reference internal" href="#responses" id="id10">Responses</a></li> |
|---|
| 68 | <li><a class="reference internal" href="#errors" id="id11">Errors</a></li> |
|---|
| 69 | </ul> |
|---|
| 70 | </li> |
|---|
| 71 | <li><a class="reference internal" href="#dht-queries" id="id12">DHT Queries</a><ul> |
|---|
| 72 | <li><a class="reference internal" href="#ping" id="id13">ping</a></li> |
|---|
| 73 | <li><a class="reference internal" href="#find-node" id="id14">find_node</a></li> |
|---|
| 74 | <li><a class="reference internal" href="#get-peers" id="id15">get_peers</a></li> |
|---|
| 75 | <li><a class="reference internal" href="#announce-peer" id="id16">announce_peer</a></li> |
|---|
| 76 | </ul> |
|---|
| 77 | </li> |
|---|
| 78 | <li><a class="reference internal" href="#references" id="id17">References</a></li> |
|---|
| 79 | </ul> |
|---|
| 80 | </div> |
|---|
| 81 | <p>BitTorrent uses a "distributed sloppy hash table" (DHT) for storing |
|---|
| 82 | peer contact information for "trackerless" torrents. In effect, each |
|---|
| 83 | peer becomes a tracker. The protocol is based on Kademila <a class="footnote-reference" href="#kademlia" id="id1">[1]</a> and is |
|---|
| 84 | implemented over UDP.</p> |
|---|
| 85 | <p>Please note the terminology used in this document to avoid |
|---|
| 86 | confusion. A "peer" is a client/server listening on a TCP port that |
|---|
| 87 | implements the BitTorrent protocol. A "node" is a client/server |
|---|
| 88 | listening on a UDP port implementing the distributed hash table |
|---|
| 89 | protocol. The DHT is composed of nodes and stores the location of |
|---|
| 90 | peers. BitTorrent clients include a DHT node, which is used to contact |
|---|
| 91 | other nodes in the DHT to get the location of peers to download from |
|---|
| 92 | using the BitTorrent protocol.</p> |
|---|
| 93 | <div class="section" id="overview"> |
|---|
| 94 | <h1>Overview</h1> |
|---|
| 95 | <p>Each node has a globally unique identifier known as the "node ID." |
|---|
| 96 | Node IDs are chosen at random from the same 160-bit space as |
|---|
| 97 | BitTorrent infohashes <a class="footnote-reference" href="#entropy" id="id2">[2]</a>. A "distance metric" is used to |
|---|
| 98 | compare two node IDs or a node ID and an infohash for "closeness." |
|---|
| 99 | Nodes must maintain a routing table containing the contact information |
|---|
| 100 | for a small number of other nodes. The routing table becomes more |
|---|
| 101 | detailed as IDs get closer to the node's own ID. Nodes know about many |
|---|
| 102 | other nodes in the DHT that have IDs that are "close" to their own but |
|---|
| 103 | have only a handful of contacts with IDs that are very far away from |
|---|
| 104 | their own.</p> |
|---|
| 105 | <p>In Kademlia, the distance metric is XOR and the result is interpreted |
|---|
| 106 | as an unsigned integer. <tt class="docutils literal"><span class="pre">distance(A,B)</span> <span class="pre">=</span> <span class="pre">|A</span> <span class="pre">xor</span> <span class="pre">B|</span></tt> Smaller values |
|---|
| 107 | are closer.</p> |
|---|
| 108 | <p>When a node wants to find peers for a torrent, it uses the distance |
|---|
| 109 | metric to compare the infohash of the torrent with the IDs of the |
|---|
| 110 | nodes in its own routing table. It then contacts the nodes it knows |
|---|
| 111 | about with IDs closest to the infohash and asks them for the contact |
|---|
| 112 | information of peers currently downloading the torrent. If a contacted |
|---|
| 113 | node knows about peers for the torrent, the peer contact information |
|---|
| 114 | is returned with the response. Otherwise, the contacted node must |
|---|
| 115 | respond with the contact information of the nodes in its routing table |
|---|
| 116 | that are closest to the infohash of the torrent. The original node |
|---|
| 117 | iteratively queries nodes that are closer to the target infohash until |
|---|
| 118 | it cannot find any closer nodes. After the search is exhausted, the |
|---|
| 119 | client then inserts the peer contact information for itself onto the |
|---|
| 120 | responding nodes with IDs closest to the infohash of the torrent.</p> |
|---|
| 121 | <p>The return value for a query for peers includes an opaque value known |
|---|
| 122 | as the "token." For a node to announce that its controlling peer is |
|---|
| 123 | downloading a torrent, it must present the token received from the |
|---|
| 124 | same queried node in a recent query for peers. When a node attempts to |
|---|
| 125 | "announce" a torrent, the queried node checks the token against the |
|---|
| 126 | querying node's IP address. This is to prevent malicious hosts from |
|---|
| 127 | signing up other hosts for torrents. Since the token is merely |
|---|
| 128 | returned by the querying node to the same node it received the token |
|---|
| 129 | from, the implementation is not defined. Tokens must be accepted for a |
|---|
| 130 | reasonable amount of time after they have been distributed. The |
|---|
| 131 | BitTorrent implementation uses the SHA1 hash of the IP address |
|---|
| 132 | concatenated onto a secret that changes every five minutes and tokens |
|---|
| 133 | up to ten minutes old are accepted.</p> |
|---|
| 134 | </div> |
|---|
| 135 | <div class="section" id="routing-table"> |
|---|
| 136 | <h1>Routing Table</h1> |
|---|
| 137 | <p>Every node maintains a routing table of known good nodes. The nodes in |
|---|
| 138 | the routing table are used as starting points for queries in the |
|---|
| 139 | DHT. Nodes from the routing table are returned in response to queries |
|---|
| 140 | from other nodes.</p> |
|---|
| 141 | <p>Not all nodes that we learn about are equal. Some are "good" and some |
|---|
| 142 | are not. Many nodes using the DHT are able to send queries and receive |
|---|
| 143 | responses, but are not able to respond to queries from other nodes. It |
|---|
| 144 | is important that each node's routing table must contain only known |
|---|
| 145 | good nodes. A good node is a node has responded to one of our queries |
|---|
| 146 | within the last 15 minutes. A node is also good if it has ever |
|---|
| 147 | responded to one of our queries and has sent us a query within the |
|---|
| 148 | last 15 minutes. After 15 minutes of inactivity, a node becomes |
|---|
| 149 | questionable. Nodes become bad when they fail to respond to multiple |
|---|
| 150 | queries in a row. Nodes that we know are good are given priority over |
|---|
| 151 | nodes with unknown status.</p> |
|---|
| 152 | <p>The routing table covers the entire node ID space from 0 to |
|---|
| 153 | 2<sup>160</sup>. The routing table is subdivided into "buckets" that |
|---|
| 154 | each cover a portion of the space. An empty table has one bucket with |
|---|
| 155 | an ID space range of min=0, max=2<sup>160</sup>. When a node with ID |
|---|
| 156 | "N" is inserted into the table, it is placed within the bucket that |
|---|
| 157 | has min &lt;= N &lt; max. An empty table has only one bucket so any |
|---|
| 158 | node must fit within it. Each bucket can only hold K nodes, currently |
|---|
| 159 | eight, before becoming "full." When a bucket is full of known good |
|---|
| 160 | nodes, no more nodes may be added unless our own node ID falls within |
|---|
| 161 | the range of the bucket. In that case, the bucket is replaced by two |
|---|
| 162 | new buckets each with half the range of the old bucket and the nodes |
|---|
| 163 | from the old bucket are distributed among the two new ones. For a new |
|---|
| 164 | table with only one bucket, the full bucket is always split into two |
|---|
| 165 | new buckets covering the ranges 0..2<sup>159</sup> and |
|---|
| 166 | 2<sup>159</sup>..2<sup>160</sup>.</p> |
|---|
| 167 | <p>When the bucket is full of good nodes, the new node is simply |
|---|
| 168 | discarded. If any nodes in the bucket are known to have become bad, |
|---|
| 169 | then one is replaced by the new node. If there are any questionable |
|---|
| 170 | nodes in the bucket have not been seen in the last 15 minutes, the |
|---|
| 171 | least recently seen node is pinged. If the pinged node responds then |
|---|
| 172 | the next least recently seen questionable node is pinged until one |
|---|
| 173 | fails to respond or all of the nodes in the bucket are known to be |
|---|
| 174 | good. If a node in the bucket fails to respond to a ping, it is |
|---|
| 175 | suggested to try once more before discarding the node and replacing it |
|---|
| 176 | with a new good node. In this way, the table fills with stable long |
|---|
| 177 | running nodes.</p> |
|---|
| 178 | <p>Each bucket should maintain a "last changed" property to |
|---|
| 179 | indicate how "fresh" the contents are. When a node in a bucket is |
|---|
| 180 | pinged and it responds, or a node is added to a bucket, or a node in a |
|---|
| 181 | bucket is replaced with another node, the bucket's last changed |
|---|
| 182 | property should be updated. Buckets that have not been changed in 15 |
|---|
| 183 | minutes should be "refreshed." This is done by picking a random ID in |
|---|
| 184 | the range of the bucket and performing a find_nodes search on it. Nodes |
|---|
| 185 | that are able to receive queries from other nodes usually do not need |
|---|
| 186 | to refresh buckets often. Nodes that are not able to receive queries |
|---|
| 187 | from other nodes usually will need to refresh all buckets periodically |
|---|
| 188 | to ensure there are good nodes in their table when the DHT is needed.</p> |
|---|
| 189 | <p>Upon inserting the first node into its routing table and when starting |
|---|
| 190 | up thereafter, the node should attempt to find the closest nodes in |
|---|
| 191 | the DHT to itself. It does this by issuing find_node messages to |
|---|
| 192 | closer and closer nodes until it cannot find any closer. The routing |
|---|
| 193 | table should be saved between invocations of the client software.</p> |
|---|
| 194 | </div> |
|---|
| 195 | <div class="section" id="bittorrent-protocol-extension"> |
|---|
| 196 | <h1>BitTorrent Protocol Extension</h1> |
|---|
| 197 | <p>The BitTorrent protocol has been extended to exchange node UDP port |
|---|
| 198 | numbers between peers that are introduced by a tracker. In this way, |
|---|
| 199 | clients can get their routing tables seeded automatically through the |
|---|
| 200 | download of regular torrents. Newly installed clients who attempt to |
|---|
| 201 | download a trackerless torrent on the first try will not have any |
|---|
| 202 | nodes in their routing table and will need the contacts included in |
|---|
| 203 | the torrent file.</p> |
|---|
| 204 | <p>Peers supporting the DHT set the last bit of the 8-byte reserved flags |
|---|
| 205 | exchanged in the BitTorrent protocol handshake. Peer receiving a |
|---|
| 206 | handshake indicating the remote peer supports the DHT should send a |
|---|
| 207 | PORT message. It begins with byte 0x09 and has a two byte payload |
|---|
| 208 | containing the UDP port of the DHT node in network byte order. Peers |
|---|
| 209 | that receive this message should attempt to ping the node on the |
|---|
| 210 | received port and IP address of the remote peer. If a response to the |
|---|
| 211 | ping is recieved, the node should attempt to insert the new contact |
|---|
| 212 | information into their routing table according to the usual rules.</p> |
|---|
| 213 | </div> |
|---|
| 214 | <div class="section" id="torrent-file-extensions"> |
|---|
| 215 | <h1>Torrent File Extensions</h1> |
|---|
| 216 | <p>A trackerless torrent dictionary does not have an "announce" key. |
|---|
| 217 | Instead, a trackerless torrent has a "nodes" key. This key should be |
|---|
| 218 | set to the K closest nodes in the torrent generating client's routing |
|---|
| 219 | table. Alternatively, the key could be set to a known good node such |
|---|
| 220 | as one operated by the person generating the torrent. Please do not |
|---|
| 221 | automatically add "router.bittorrent.com" to torrent files or |
|---|
| 222 | automatically add this node to clients routing tables.</p> |
|---|
| 223 | <pre class="literal-block"> |
|---|
| 224 | nodes = [["<host>", <port>], ["<host>", <port>], ...] |
|---|
| 225 | nodes = [["127.0.0.1", 6881], ["your.router.node", 4804]] |
|---|
| 226 | </pre> |
|---|
| 227 | </div> |
|---|
| 228 | <div class="section" id="krpc-protocol"> |
|---|
| 229 | <h1>KRPC Protocol</h1> |
|---|
| 230 | <p>The KRPC protocol is a simple RPC mechanism consisting of bencoded |
|---|
| 231 | dictionaries sent over UDP. A single query packet is sent out and a |
|---|
| 232 | single packet is sent in response. There is no retry. There are three |
|---|
| 233 | message types: query, response, and error. For the DHT protocol, there |
|---|
| 234 | are four queries: ping, find_node, get_peers, and announce_peer.</p> |
|---|
| 235 | <p>A KRPC message is a single dictionary with two keys common to |
|---|
| 236 | every message and additional keys depending on the type of message. |
|---|
| 237 | Every message has a key "t" with a string value representing a transaction |
|---|
| 238 | ID. This transaction ID is generated by the querying node and is echoed |
|---|
| 239 | in the response, so responses may be correlated with multiple queries |
|---|
| 240 | to the same node. The transaction ID should be encoded as a short string |
|---|
| 241 | of binary numbers, typically 2 characters are enough as they cover 2^16 |
|---|
| 242 | outstanding queries. The other key contained in every KRPC message is "y" |
|---|
| 243 | with a single character value describing the type of message. The value |
|---|
| 244 | of the "y" key is one of "q" for query, "r" for response, or "e" for |
|---|
| 245 | error.</p> |
|---|
| 246 | <div class="section" id="contact-encoding"> |
|---|
| 247 | <h2>Contact Encoding</h2> |
|---|
| 248 | <p>Contact information for peers is encoded as a 6-byte string. Also |
|---|
| 249 | known as "Compact IP-address/port info" the 4-byte IP address is in |
|---|
| 250 | network byte order with the 2 byte port in network byte order |
|---|
| 251 | concatenated onto the end.</p> |
|---|
| 252 | <p>Contact information for nodes is encoded as a 26-byte string. |
|---|
| 253 | Also known as "Compact node info" the 20-byte Node ID in network byte |
|---|
| 254 | order has the compact IP-address/port info concatenated to the end.</p> |
|---|
| 255 | </div> |
|---|
| 256 | <div class="section" id="queries"> |
|---|
| 257 | <h2>Queries</h2> |
|---|
| 258 | <p>Queries, or KRPC message dictionaries with a "y" value of "q", |
|---|
| 259 | contain two additional keys; "q" and "a". Key "q" has a string value |
|---|
| 260 | containing the method name of the query. Key "a" has a dictionary value |
|---|
| 261 | containing named arguments to the query.</p> |
|---|
| 262 | </div> |
|---|
| 263 | <div class="section" id="responses"> |
|---|
| 264 | <h2>Responses</h2> |
|---|
| 265 | <p>Responses, or KRPC message dictionaries with a "y" value of "r", |
|---|
| 266 | contain one additional key "r". The value of "r" is a dictionary |
|---|
| 267 | containing named return values. Response messages are sent upon |
|---|
| 268 | successful completion of a query.</p> |
|---|
| 269 | </div> |
|---|
| 270 | <div class="section" id="errors"> |
|---|
| 271 | <h2>Errors</h2> |
|---|
| 272 | <p>Errors, or KRPC message dictionaries with a "y" value of "e", |
|---|
| 273 | contain one additional key "e". The value of "e" is a list. The first |
|---|
| 274 | element is an integer representing the error code. The second element |
|---|
| 275 | is a string containing the error message. Errors are sent when a query |
|---|
| 276 | cannot be fulfilled. The following table describes the possible error |
|---|
| 277 | codes:</p> |
|---|
| 278 | <table border="1" class="docutils"> |
|---|
| 279 | <colgroup> |
|---|
| 280 | <col width="19%" /> |
|---|
| 281 | <col width="81%" /> |
|---|
| 282 | </colgroup> |
|---|
| 283 | <tbody valign="top"> |
|---|
| 284 | <tr><td>Code</td> |
|---|
| 285 | <td>Description</td> |
|---|
| 286 | </tr> |
|---|
| 287 | <tr><td>201</td> |
|---|
| 288 | <td>Generic Error</td> |
|---|
| 289 | </tr> |
|---|
| 290 | <tr><td>202</td> |
|---|
| 291 | <td>Server Error</td> |
|---|
| 292 | </tr> |
|---|
| 293 | <tr><td>203</td> |
|---|
| 294 | <td>Protocol Error, such as a malformed |
|---|
| 295 | packet, invalid arguments, or bad token</td> |
|---|
| 296 | </tr> |
|---|
| 297 | <tr><td>204</td> |
|---|
| 298 | <td>Method Unknown</td> |
|---|
| 299 | </tr> |
|---|
| 300 | </tbody> |
|---|
| 301 | </table> |
|---|
| 302 | <p>Example Error Packets:</p> |
|---|
| 303 | <pre class="literal-block"> |
|---|
| 304 | generic error = {"t":"aa", "y":"e", "e":[201, "A Generic Error Ocurred"]} |
|---|
| 305 | bencoded = d1:eli201e23:A Generic Error Ocurrede1:t2:aa1:y1:ee |
|---|
| 306 | </pre> |
|---|
| 307 | </div> |
|---|
| 308 | </div> |
|---|
| 309 | <div class="section" id="dht-queries"> |
|---|
| 310 | <h1>DHT Queries</h1> |
|---|
| 311 | <p>All queries have an "id" key and value containing the node ID of the |
|---|
| 312 | querying node. All responses have an "id" key and value containing the |
|---|
| 313 | node ID of the responding node.</p> |
|---|
| 314 | <div class="section" id="ping"> |
|---|
| 315 | <h2>ping</h2> |
|---|
| 316 | <p>The most basic query is a ping. "q" = "ping" A ping query has a |
|---|
| 317 | single argument, "id" the value is a 20-byte string containing the |
|---|
| 318 | senders node ID in network byte order. The appropriate response to a |
|---|
| 319 | ping has a single key "id" containing the node ID of the responding |
|---|
| 320 | node.</p> |
|---|
| 321 | <pre class="literal-block"> |
|---|
| 322 | arguments: {"id"&nbsp;: "<querying nodes id>"} |
|---|
| 323 | |
|---|
| 324 | response: {"id"&nbsp;: "<queried nodes id>"} |
|---|
| 325 | </pre> |
|---|
| 326 | <p>Example Packets</p> |
|---|
| 327 | <pre class="literal-block"> |
|---|
| 328 | ping Query = {"t":"aa", "y":"q", "q":"ping", "a":{"id":"abcdefghij0123456789"}} |
|---|
| 329 | bencoded = d1:ad2:id20:abcdefghij0123456789e1:q4:ping1:t2:aa1:y1:qe |
|---|
| 330 | </pre> |
|---|
| 331 | <pre class="literal-block"> |
|---|
| 332 | Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}} |
|---|
| 333 | bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re |
|---|
| 334 | </pre> |
|---|
| 335 | </div> |
|---|
| 336 | <div class="section" id="find-node"> |
|---|
| 337 | <h2>find_node</h2> |
|---|
| 338 | <p>Find node is used to find the contact information for a node given |
|---|
| 339 | its ID. "q" == "find_node" A find_node query has two arguments, "id" |
|---|
| 340 | containing the node ID of the querying node, and "target" containing |
|---|
| 341 | the ID of the node sought by the queryer. When a node receives a |
|---|
| 342 | find_node query, it should respond with a key "nodes" and value of a |
|---|
| 343 | string containing the compact node info for the target node or the K |
|---|
| 344 | (8) closest good nodes in its own routing table.</p> |
|---|
| 345 | <pre class="literal-block"> |
|---|
| 346 | arguments: {"id"&nbsp;: "<querying nodes id>", "target"&nbsp;: "<id of target node>"} |
|---|
| 347 | |
|---|
| 348 | response: {"id"&nbsp;: "<queried nodes id>", "nodes"&nbsp;: "<compact node info>"} |
|---|
| 349 | </pre> |
|---|
| 350 | <p>Example Packets</p> |
|---|
| 351 | <pre class="literal-block"> |
|---|
| 352 | find_node Query = {"t":"aa", "y":"q", "q":"find_node", "a": {"id":"abcdefghij0123456789", "target":"mnopqrstuvwxyz123456"}} |
|---|
| 353 | bencoded = d1:ad2:id20:abcdefghij01234567896:target20:mnopqrstuvwxyz123456e1:q9:find_node1:t2:aa1:y1:qe |
|---|
| 354 | </pre> |
|---|
| 355 | <pre class="literal-block"> |
|---|
| 356 | Response = {"t":"aa", "y":"r", "r": {"id":"0123456789abcdefghij", "nodes": "def456..."}} |
|---|
| 357 | bencoded = d1:rd2:id20:0123456789abcdefghij5:nodes9:def456...e1:t2:aa1:y1:re |
|---|
| 358 | </pre> |
|---|
| 359 | </div> |
|---|
| 360 | <div class="section" id="get-peers"> |
|---|
| 361 | <h2>get_peers</h2> |
|---|
| 362 | <p>Get peers associated with a torrent infohash. "q" = "get_peers" A |
|---|
| 363 | get_peers query has two arguments, "id" containing the node ID of the |
|---|
| 364 | querying node, and "info_hash" containing the infohash of the torrent. |
|---|
| 365 | If the queried node has peers for the infohash, they are returned in a |
|---|
| 366 | key "values" as a list of strings. Each string containing "compact" format |
|---|
| 367 | peer information for a single peer. If the queried node has no |
|---|
| 368 | peers for the infohash, a key "nodes" is returned containing the K |
|---|
| 369 | nodes in the queried nodes routing table closest to the infohash |
|---|
| 370 | supplied in the query. In either case a "token" key is also included in |
|---|
| 371 | the return value. The token value is a required argument for a future |
|---|
| 372 | announce_peer query. The token value should be a short binary string.</p> |
|---|
| 373 | <pre class="literal-block"> |
|---|
| 374 | arguments: {"id"&nbsp;: "<querying nodes id>", "info_hash"&nbsp;: "<20-byte infohash of target torrent>"} |
|---|
| 375 | |
|---|
| 376 | response: {"id"&nbsp;: "<queried nodes id>", "token"&nbsp;:"<opaque write token>", "values"&nbsp;: ["<peer 1 info string>", "<peer 2 info string>"]} |
|---|
| 377 | |
|---|
| 378 | or: {"id"&nbsp;: "<queried nodes id>", "token"&nbsp;:"<opaque write token>", "nodes"&nbsp;: "<compact node info>"} |
|---|
| 379 | </pre> |
|---|
| 380 | <p>Example Packets:</p> |
|---|
| 381 | <pre class="literal-block"> |
|---|
| 382 | get_peers Query = {"t":"aa", "y":"q", "q":"get_peers", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456"}} |
|---|
| 383 | bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:mnopqrstuvwxyz123456e1:q9:get_peers1:t2:aa1:y1:qe |
|---|
| 384 | </pre> |
|---|
| 385 | <pre class="literal-block"> |
|---|
| 386 | Response with peers = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "values": ["axje.u", "idhtnm"]}} |
|---|
| 387 | bencoded = d1:rd2:id20:abcdefghij01234567895:token8:aoeusnth6:valuesl6:axje.u6:idhtnmee1:t2:aa1:y1:re |
|---|
| 388 | </pre> |
|---|
| 389 | <pre class="literal-block"> |
|---|
| 390 | Response with closest nodes = {"t":"aa", "y":"r", "r": {"id":"abcdefghij0123456789", "token":"aoeusnth", "nodes": "def456..."}} |
|---|
| 391 | bencoded = d1:rd2:id20:abcdefghij01234567895:nodes9:def456...5:token8:aoeusnthe1:t2:aa1:y1:re |
|---|
| 392 | </pre> |
|---|
| 393 | </div> |
|---|
| 394 | <div class="section" id="announce-peer"> |
|---|
| 395 | <h2>announce_peer</h2> |
|---|
| 396 | <p>Announce that the peer, controlling the querying node, is downloading |
|---|
| 397 | a torrent on a port. announce_peer has four arguments: "id" containing the node ID of the |
|---|
| 398 | querying node, "info_hash" containing the infohash of the torrent, |
|---|
| 399 | "port" containing the port as an integer, and the "token" received in |
|---|
| 400 | response to a previous get_peers query. The queried node must verify |
|---|
| 401 | that the token was previously sent to the same IP address as the |
|---|
| 402 | querying node. Then the queried node should store the IP address of the |
|---|
| 403 | querying node and the supplied port number under the infohash in its |
|---|
| 404 | store of peer contact information.</p> |
|---|
| 405 | <pre class="literal-block"> |
|---|
| 406 | arguments: {"id" : "<querying nodes id>", "info_hash" : "<20-byte infohash of target torrent>", "port" : <port number>, "token" : "<opaque token>"} |
|---|
| 407 | |
|---|
| 408 | response: {"id" : "<queried nodes id>"} |
|---|
| 409 | </pre> |
|---|
| 410 | <p>Example Packets:</p> |
|---|
| 411 | <pre class="literal-block"> |
|---|
| 412 | announce_peers Query = {"t":"aa", "y":"q", "q":"announce_peer", "a": {"id":"abcdefghij0123456789", "info_hash":"mnopqrstuvwxyz123456", "port": 6881, "token": "aoeusnth"}} |
|---|
| 413 | bencoded = d1:ad2:id20:abcdefghij01234567899:info_hash20:<br /> |
|---|
| 414 | mnopqrstuvwxyz1234564:porti6881e5:token8:aoeusnthe1:q13:announce_peer1:t2:aa1:y1:qe |
|---|
| 415 | </pre> |
|---|
| 416 | <pre class="literal-block"> |
|---|
| 417 | Response = {"t":"aa", "y":"r", "r": {"id":"mnopqrstuvwxyz123456"}} |
|---|
| 418 | bencoded = d1:rd2:id20:mnopqrstuvwxyz123456e1:t2:aa1:y1:re |
|---|
| 419 | </pre> |
|---|
| 420 | </div> |
|---|
| 421 | </div> |
|---|
| 422 | <div class="section" id="references"> |
|---|
| 423 | <h1>References</h1> |
|---|
| 424 | <table class="docutils footnote" frame="void" id="kademlia" rules="none"> |
|---|
| 425 | <colgroup><col class="label" /><col /></colgroup> |
|---|
| 426 | <tbody valign="top"> |
|---|
| 427 | <tr><td class="label"><a class="fn-backref" href="#id1">[1]</a></td><td>Peter Maymounkov, David Mazieres, "Kademlia: A Peer-to-peer Information System Based on the XOR Metric", <em>IPTPS 2002</em>. <a class="reference external" href="http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf">http://www.cs.rice.edu/Conferences/IPTPS02/109.pdf</a></td></tr> |
|---|
| 428 | </tbody> |
|---|
| 429 | </table> |
|---|
| 430 | <table class="docutils footnote" frame="void" id="entropy" rules="none"> |
|---|
| 431 | <colgroup><col class="label" /><col /></colgroup> |
|---|
| 432 | <tbody valign="top"> |
|---|
| 433 | <tr><td class="label"><a class="fn-backref" href="#id2">[2]</a></td><td>Use SHA1 and plenty of entropy to ensure a unique ID.</td></tr> |
|---|
| 434 | </tbody> |
|---|
| 435 | </table> |
|---|
| 436 | <!-- Local Variables: |
|---|
| 437 | mode: indented-text |
|---|
| 438 | indent-tabs-mode: nil |
|---|
| 439 | sentence-end-double-space: t |
|---|
| 440 | fill-column: 70 |
|---|
| 441 | coding: utf-8 |
|---|
| 442 | End: --> |
|---|
| 443 | </div> |
|---|
| 444 | |
|---|
| 445 | |
|---|
| 446 | </div> |
|---|
| 447 | <div id="footer"> |
|---|
| 448 | <hr/> |
|---|
| 449 | </div> |
|---|
| 450 | |
|---|
| 451 | </div> |
|---|
| 452 | </body> |
|---|
| 453 | </html> |
|---|