clarify some DHT extensions in docs
This commit is contained in:
parent
10003f952f
commit
6769df7508
|
@ -64,6 +64,14 @@ among the 8 closest nodes of the info hash. libtorrent also keeps traversing
|
|||
nodes using get_peers until it has found the 8 closest ones, and then announces
|
||||
to those nodes.</p>
|
||||
</div>
|
||||
<div class="section" id="forward-compatibility">
|
||||
<h2>forward compatibility</h2>
|
||||
<p>In order to support future DHT messages, any message which is not recognized
|
||||
but has either an <tt class="docutils literal"><span class="pre">info_hash</span></tt> or <tt class="docutils literal"><span class="pre">target</span></tt> argument is interpreted as
|
||||
find node for that target. i.e. it returns nodes. This allows future messages
|
||||
to be properly forwarded by clients that don't understand them instead of
|
||||
being blocked.</p>
|
||||
</div>
|
||||
<div class="section" id="client-identification">
|
||||
<h2>client identification</h2>
|
||||
<p>In each DHT packet, an extra key is inserted named "v". This is a string
|
||||
|
@ -95,6 +103,7 @@ as a binary number describing the client version.</p>
|
|||
</div>
|
||||
<div class="section" id="ipv6-support">
|
||||
<h2>IPv6 support</h2>
|
||||
<p><strong>This extension is superseeded by</strong> <a class="reference external" href="http://bittorrent.org/beps/bep_0032.html">BEP 32</a>.</p>
|
||||
<p>The DHT messages that don't support IPv6 are the <tt class="docutils literal"><span class="pre">nodes</span></tt> replies.
|
||||
They encode all the contacts as 6 bytes packed together in sequence in a
|
||||
string. The problem is that IPv6 endpoints cannot be encoded as 6 bytes, but
|
||||
|
|
|
@ -15,6 +15,15 @@ among the 8 closest nodes of the info hash. libtorrent also keeps traversing
|
|||
nodes using get_peers until it has found the 8 closest ones, and then announces
|
||||
to those nodes.
|
||||
|
||||
forward compatibility
|
||||
---------------------
|
||||
|
||||
In order to support future DHT messages, any message which is not recognized
|
||||
but has either an ``info_hash`` or ``target`` argument is interpreted as
|
||||
find node for that target. i.e. it returns nodes. This allows future messages
|
||||
to be properly forwarded by clients that don't understand them instead of
|
||||
being blocked.
|
||||
|
||||
client identification
|
||||
---------------------
|
||||
|
||||
|
@ -39,6 +48,10 @@ Currently known clients:
|
|||
IPv6 support
|
||||
------------
|
||||
|
||||
**This extension is superseeded by** `BEP 32`_.
|
||||
|
||||
.. _`BEP 32`: http://bittorrent.org/beps/bep_0032.html
|
||||
|
||||
The DHT messages that don't support IPv6 are the ``nodes`` replies.
|
||||
They encode all the contacts as 6 bytes packed together in sequence in a
|
||||
string. The problem is that IPv6 endpoints cannot be encoded as 6 bytes, but
|
||||
|
|
Loading…
Reference in New Issue