[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated: use US english
From: |
gnunet |
Subject: |
[lsd0004] branch master updated: use US english |
Date: |
Sat, 12 Mar 2022 04:23:40 +0100 |
This is an automated email from the git hooks/post-receive script.
grothoff pushed a commit to branch master
in repository lsd0004.
The following commit(s) were added to refs/heads/master by this push:
new d7ba2ad use US english
d7ba2ad is described below
commit d7ba2ade4b8c3224a706effe251cc2f575cefa81
Author: Christian Grothoff <grothoff@gnunet.org>
AuthorDate: Sat Mar 12 04:23:35 2022 +0100
use US english
---
draft-schanzen-r5n.xml | 36 ++++++++++++++++++------------------
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index efa3994..65dc78f 100644
--- 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
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [lsd0004] branch master updated: use US english,
gnunet <=