From b39f0f797f25e25129174efbd8c85ec6ed683356 Mon Sep 17 00:00:00 2001 From: Adrian Pascu Date: Mon, 8 Mar 2021 17:54:06 +0200 Subject: [PATCH] Fix DHT typo --- beps/bep_0005.html | 2 +- beps/bep_0005.rst | 2 +- beps/bep_0032.html | 16 ++++++++-------- beps/bep_0032.rst | 16 ++++++++-------- 4 files changed, 18 insertions(+), 18 deletions(-) diff --git a/beps/bep_0005.html b/beps/bep_0005.html index dfd5d5a..e09af0e 100644 --- a/beps/bep_0005.html +++ b/beps/bep_0005.html @@ -156,7 +156,7 @@

Routing Table

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 diff --git a/beps/bep_0005.rst b/beps/bep_0005.rst index 3df7b7e..ca79147 100644 --- a/beps/bep_0005.rst +++ b/beps/bep_0005.rst @@ -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 diff --git a/beps/bep_0032.html b/beps/bep_0032.html index b990f2f..782ad95 100644 --- a/beps/bep_0032.html +++ b/beps/bep_0032.html @@ -90,7 +90,7 @@

Operation

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.

@@ -107,7 +107,7 @@

Dual-stack nodes

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.

@@ -184,7 +184,7 @@

Changes to the BitTorrent protocol

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

@@ -216,12 +216,12 @@

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

@@ -243,10 +243,10 @@

want

Changes to message semantics

-

find_nodes and get_peers

-

A node sending a find_nodes or get_peers request may include a "want" +

find_node and get_peers

+

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".

diff --git a/beps/bep_0032.rst b/beps/bep_0032.rst index fd3f24d..5a46120 100644 --- a/beps/bep_0032.rst +++ b/beps/bep_0032.rst @@ -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. @@ -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. @@ -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 @@ -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 @@ -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".