commit d7ba2ade4b8c3224a706effe251cc2f575cefa81
parent fe787e7b155ce7399a5669a21470652150af835b
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Sat, 12 Mar 2022 04:23:35 +0100
use US english
Diffstat:
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -208,9 +208,9 @@
512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s can be
stored under the same key. <tt>Peer Addresses</tt> are valid keys.
</dd>
- <dt>Neighbour:</dt>
+ <dt>Neighbor:</dt>
<dd>
- A neighbour is a peer which is directly able to communicate
+ A neighbor is a peer which is directly able to communicate
with our peer via the <tt>Underlay Interface</tt>.
</dd>
<dt>Block:</dt>
@@ -652,7 +652,7 @@ Connectivity | |Underlay| |Underlay|
<t>
The frequency of advertisement and peer discovery messages
<bcp14>MAY</bcp14> be adapted according to network conditions,
- the set of already connected neighbours,
+ the set of already connected neighbors,
the workload of the system and other factors which are at the discretion of
the developer.
</t>
@@ -766,16 +766,16 @@ bchar = *(ALPHA / DIGIT)
</t>
<t>
To enable routing, any R<sup>5</sup>N implementation must keep
- information about its current set of neighbours.
+ information about its current set of neighbors.
Upon receiving a connection notification from the Underlay through
- <tt>PEER_CONNECTED</tt>, information on the new neighbour
+ <tt>PEER_CONNECTED</tt>, information on the new neighbor
<bcp14>MUST</bcp14> be added, and similarly when
a disconnect is indicated by the Underlay through
<tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed.
</t>
<t>
In order to achieve O(log n) routing performance,
- the data structure for managing neighbours and their
+ the data structure for managing neighbors and their
metadata <bcp14>MUST</bcp14> be implemented using the k-buckets concept of
<xref target="Kademlia"/> as defined in <xref target="routing_table"/>.
Maintenance of the routing table (after bootstrapping) is
@@ -792,11 +792,11 @@ bchar = *(ALPHA / DIGIT)
<name>Routing Table</name>
<t>
The routing table consists of an array of k-buckets. Each
- k-bucket contains a list of neighbours.
- The i-th k-bucket stores neighbours whose
+ k-bucket contains a list of neighbors.
+ The i-th k-bucket stores neighbors whose
identifiers are between distance 2^i and 2^(i+1) from the local peer.
System constraints will typically force an implementation to impose some
- upper limit on the number of neighbours kept per k-bucket.
+ upper limit on the number of neighbors kept per k-bucket.
</t>
<t>
Implementations <bcp14>SHOULD</bcp14> try to keep at least
@@ -812,7 +812,7 @@ bchar = *(ALPHA / DIGIT)
If a system hits constraints with respect to
the number of active connections, an implementation
<bcp14>MUST</bcp14> evict peers from those k-buckets with the
- largest number of neighbours. The eviction strategy <bcp14>MUST</bcp14> be
+ largest number of neighbors. The eviction strategy <bcp14>MUST</bcp14> be
to drop the shortest-lived connections first.
</t>
</section>
@@ -821,7 +821,7 @@ bchar = *(ALPHA / DIGIT)
<t>
To build its routing table, a peer will send out requests
asking for blocks of type HELLO using its own location as the key,
- but filtering all of its neighbours via the Bloom filter described
+ but filtering all of its neighbors via the Bloom filter described
in <xref target="result_bloomfilter"/>.
These requests <bcp14>MUST</bcp14> use the FindApproximate and DemultiplexEverywhere
flags. FindApproximate will ensure that other peers will reply
@@ -890,7 +890,7 @@ bchar = *(ALPHA / DIGIT)
<tt>SelectClosestpeer(K, B) -> N</tt>
</dt>
<dd>
- This function selects the neighbour <tt>N</tt> from our
+ This function selects the neighbor <tt>N</tt> from our
routing table with the shortest XOR-distance to the key <tt>K</tt>.
This means that for all other peers <tt>N'</tt> in the routing table
<tt>GetDistance(N, K) < GetDistance(N',K)</tt>.
@@ -902,7 +902,7 @@ bchar = *(ALPHA / DIGIT)
</dt>
<dd>
This function selects a random peer <tt>N</tt> from
- all neighbours.
+ all neighbors.
Peers with a positive test in the peer Bloom
filter <tt>B</tt> are not considered.
</dd>
@@ -910,7 +910,7 @@ bchar = *(ALPHA / DIGIT)
<tt>Selectpeer(K, H, B) -> N</tt>
</dt>
<dd>
- This function selects a neighbour <tt>N</tt> depending on the
+ This function selects a neighbor <tt>N</tt> depending on the
number of hops <tt>H</tt> parameter.
If <tt>H < NETWORK_SIZE_ESTIMATE</tt>
this function <bcp14>MUST</bcp14> return <tt>SelectRandompeer(B)</tt> and
@@ -928,7 +928,7 @@ bchar = *(ALPHA / DIGIT)
<tt>ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE) -> Number</tt>
</dt>
<dd>
- This function computes the number of neighbours
+ This function computes the number of neighbors
that a message should be forwarded to. The arguments
are the desired replication level (<tt>REPL_LVL</tt>), the <tt>HOPCOUNT</tt> of the message so far, and
the base-2 logarithm of the current network
@@ -1119,7 +1119,7 @@ bchar = *(ALPHA / DIGIT)
<section anchor="p2p_hello" numbered="true" toc="default">
<name>HelloMessage</name>
<t>
- <tt>HelloMessage</tt>s are used to inform neighbours of
+ <tt>HelloMessage</tt>s are used to inform neighbors of
a peer about the sender's available addresses. The
recipients use these messages to inform their respective
Underlays about ways to sustain the connections and to
@@ -1220,7 +1220,7 @@ bchar = *(ALPHA / DIGIT)
The address information about P should then also be made
available to each respective Underlays to enable the
Underlay to maintain optimal connectivity to the
- neighbour.
+ neighbor.
</t>
</section>
</section>
@@ -2160,7 +2160,7 @@ gnunet+tcp://12.3.4.5/ \
does not have/require a trust anchor a priori. This is (again) in contrast
to RELOAD -->
<t>
- If an upper bound to the maximum number of neighbours in a
+ If an upper bound to the maximum number of neighbors in a
k-bucket is reached, the implementation <bcp14>MUST</bcp14>
prefer to preserve the oldest working connections instead of
new connections. This makes Sybil attacks less effective
