Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fix DHT typo #119

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Fix DHT typo #119

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion beps/bep_0005.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,7 +156,7 @@ <h1>Routing Table</h1>
bucket is replaced with another node, the bucket's last changed
property should be updated. Buckets that have not been changed in 15
minutes should be &quot;refreshed.&quot; This is done by picking a random ID in
the range of the bucket and performing a find_nodes search on it. Nodes
the range of the bucket and performing a find_node search on it. Nodes
that are able to receive queries from other nodes usually do not need
to refresh buckets often. Nodes that are not able to receive queries
from other nodes usually will need to refresh all buckets periodically
Expand Down
2 changes: 1 addition & 1 deletion beps/bep_0005.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -124,7 +124,7 @@ pinged and it responds, or a node is added to a bucket, or a node in a
bucket is replaced with another node, the bucket's last changed
property should be updated. Buckets that have not been changed in 15
minutes should be "refreshed." This is done by picking a random ID in
the range of the bucket and performing a find_nodes search on it. Nodes
the range of the bucket and performing a find_node search on it. Nodes
that are able to receive queries from other nodes usually do not need
to refresh buckets often. Nodes that are not able to receive queries
from other nodes usually will need to refresh all buckets periodically
Expand Down
16 changes: 8 additions & 8 deletions beps/bep_0032.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -90,7 +90,7 @@ <h1>Operation</h1>
slightly increases efficiency in the case where the two DHTs are
mostly congruent.</p>
<p>Usually, messages only carry data in the address family implied by the
network layer protocol. In the case of the find_nodes and get_peers
network layer protocol. In the case of the find_node and get_peers
requests, however, the requestor may optionally request that the reply
should contain IPv4 node information, IPv6 node information, or both.</p>
<div class="section" id="single-protocol-nodes">
Expand All @@ -107,7 +107,7 @@ <h2>Dual-stack nodes</h2>
two DHTs, as described in the following sections.</p>
<div class="section" id="bootstrapping">
<h3>Bootstrapping</h3>
<p>A dual-stack node that is bootstrapping its DHT will send find_nodes
<p>A dual-stack node that is bootstrapping its DHT will send find_node
requests in order to populate its routing tables. In order to accelerate
this process, it should request both IPv4 and IPv6 node information.</p>
</div>
Expand Down Expand Up @@ -184,7 +184,7 @@ <h1>Changes to the BitTorrent protocol</h1>
message for both address families. However, since an implementation
need not participate in both DHTs, nor use the same port in both
DHTs, this specification leaves the role of bridging the two DHTs to
the 'find_nodes' message (see below).</blockquote>
the 'find_node' message (see below).</blockquote>
</div>
<div class="section" id="changes-and-extensions-to-existing-messages">
<h1>Changes and extensions to existing messages</h1>
Expand Down Expand Up @@ -216,12 +216,12 @@ <h3>nodes6</h3>
<p>The &quot;nodes6&quot; parameter is analogous to the &quot;nodes&quot; parameter: when
present, it carries a string containing the compact IPv6 node
information for the 8 closest good nodes in the sending node's IPv6
routing table. This parameter is allowed in replies to the find_nodes
routing table. This parameter is allowed in replies to the find_node
and get_peers messages (see below).</p>
</div>
<div class="section" id="want">
<h3>want</h3>
<p>The &quot;want&quot; parameter is allowed in the find_nodes and get_peers requests,
<p>The &quot;want&quot; parameter is allowed in the find_node and get_peers requests,
and governs the presence or absence of the &quot;nodes&quot; and &quot;nodes6&quot; parameters
in the requested reply. Its value is a list of one or more strings, which
may include</p>
Expand All @@ -243,10 +243,10 @@ <h3>want</h3>
<div class="section" id="changes-to-message-semantics">
<h2>Changes to message semantics</h2>
<div class="section" id="find-nodes-and-get-peers">
<h3>find_nodes and get_peers</h3>
<p>A node sending a find_nodes or get_peers request may include a &quot;want&quot;
<h3>find_node and get_peers</h3>
<p>A node sending a find_node or get_peers request may include a &quot;want&quot;
parameter containing one or both of the strings &quot;n4&quot; or &quot;n6&quot;. A node
replying to a find_nodes or get_peers request that includes a &quot;want&quot;
replying to a find_node or get_peers request that includes a &quot;want&quot;
parameter should include a &quot;nodes&quot; parameter if the request's &quot;want&quot;
parameter contained the string &quot;n4&quot;, and should include a &quot;nodes6&quot;
parameter if the request's &quot;want&quot; parameter contained the string &quot;n6&quot;.</p>
Expand Down
16 changes: 8 additions & 8 deletions beps/bep_0032.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -53,7 +53,7 @@ slightly increases efficiency in the case where the two DHTs are
mostly congruent.

Usually, messages only carry data in the address family implied by the
network layer protocol. In the case of the find_nodes and get_peers
network layer protocol. In the case of the find_node and get_peers
requests, however, the requestor may optionally request that the reply
should contain IPv4 node information, IPv6 node information, or both.

Expand All @@ -78,7 +78,7 @@ two DHTs, as described in the following sections.
Bootstrapping
'''''''''''''

A dual-stack node that is bootstrapping its DHT will send find_nodes
A dual-stack node that is bootstrapping its DHT will send find_node
requests in order to populate its routing tables. In order to accelerate
this process, it should request both IPv4 and IPv6 node information.

Expand Down Expand Up @@ -164,7 +164,7 @@ the DHT.
message for both address families. However, since an implementation
need not participate in both DHTs, nor use the same port in both
DHTs, this specification leaves the role of bridging the two DHTs to
the 'find_nodes' message (see below).
the 'find_node' message (see below).


Changes and extensions to existing messages
Expand Down Expand Up @@ -204,14 +204,14 @@ nodes6
The "nodes6" parameter is analogous to the "nodes" parameter: when
present, it carries a string containing the compact IPv6 node
information for the 8 closest good nodes in the sending node's IPv6
routing table. This parameter is allowed in replies to the find_nodes
routing table. This parameter is allowed in replies to the find_node
and get_peers messages (see below).


want
''''

The "want" parameter is allowed in the find_nodes and get_peers requests,
The "want" parameter is allowed in the find_node and get_peers requests,
and governs the presence or absence of the "nodes" and "nodes6" parameters
in the requested reply. Its value is a list of one or more strings, which
may include
Expand All @@ -232,12 +232,12 @@ and must be silently ignored on reception.
Changes to message semantics
----------------------------

find_nodes and get_peers
find_node and get_peers
''''''''''''''''''''''''

A node sending a find_nodes or get_peers request may include a "want"
A node sending a find_node or get_peers request may include a "want"
parameter containing one or both of the strings "n4" or "n6". A node
replying to a find_nodes or get_peers request that includes a "want"
replying to a find_node or get_peers request that includes a "want"
parameter should include a "nodes" parameter if the request's "want"
parameter contained the string "n4", and should include a "nodes6"
parameter if the request's "want" parameter contained the string "n6".
Expand Down