diff options
Diffstat (limited to 'draft-schanzen-r5n.xml')
-rw-r--r-- | draft-schanzen-r5n.xml | 36 |
1 files 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 @@ | |||
208 | 512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s can be | 208 | 512-bit identifier of a location in the DHT. Multiple <tt>Block</tt>s can be |
209 | stored under the same key. <tt>Peer Addresses</tt> are valid keys. | 209 | stored under the same key. <tt>Peer Addresses</tt> are valid keys. |
210 | </dd> | 210 | </dd> |
211 | <dt>Neighbour:</dt> | 211 | <dt>Neighbor:</dt> |
212 | <dd> | 212 | <dd> |
213 | A neighbour is a peer which is directly able to communicate | 213 | A neighbor is a peer which is directly able to communicate |
214 | with our peer via the <tt>Underlay Interface</tt>. | 214 | with our peer via the <tt>Underlay Interface</tt>. |
215 | </dd> | 215 | </dd> |
216 | <dt>Block:</dt> | 216 | <dt>Block:</dt> |
@@ -652,7 +652,7 @@ Connectivity | |Underlay| |Underlay| | |||
652 | <t> | 652 | <t> |
653 | The frequency of advertisement and peer discovery messages | 653 | The frequency of advertisement and peer discovery messages |
654 | <bcp14>MAY</bcp14> be adapted according to network conditions, | 654 | <bcp14>MAY</bcp14> be adapted according to network conditions, |
655 | the set of already connected neighbours, | 655 | the set of already connected neighbors, |
656 | the workload of the system and other factors which are at the discretion of | 656 | the workload of the system and other factors which are at the discretion of |
657 | the developer. | 657 | the developer. |
658 | </t> | 658 | </t> |
@@ -766,16 +766,16 @@ bchar = *(ALPHA / DIGIT) | |||
766 | </t> | 766 | </t> |
767 | <t> | 767 | <t> |
768 | To enable routing, any R<sup>5</sup>N implementation must keep | 768 | To enable routing, any R<sup>5</sup>N implementation must keep |
769 | information about its current set of neighbours. | 769 | information about its current set of neighbors. |
770 | Upon receiving a connection notification from the Underlay through | 770 | Upon receiving a connection notification from the Underlay through |
771 | <tt>PEER_CONNECTED</tt>, information on the new neighbour | 771 | <tt>PEER_CONNECTED</tt>, information on the new neighbor |
772 | <bcp14>MUST</bcp14> be added, and similarly when | 772 | <bcp14>MUST</bcp14> be added, and similarly when |
773 | a disconnect is indicated by the Underlay through | 773 | a disconnect is indicated by the Underlay through |
774 | <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed. | 774 | <tt>PEER_DISCONNECTED</tt> the peer <bcp14>MUST</bcp14> be removed. |
775 | </t> | 775 | </t> |
776 | <t> | 776 | <t> |
777 | In order to achieve O(log n) routing performance, | 777 | In order to achieve O(log n) routing performance, |
778 | the data structure for managing neighbours and their | 778 | the data structure for managing neighbors and their |
779 | metadata <bcp14>MUST</bcp14> be implemented using the k-buckets concept of | 779 | metadata <bcp14>MUST</bcp14> be implemented using the k-buckets concept of |
780 | <xref target="Kademlia"/> as defined in <xref target="routing_table"/>. | 780 | <xref target="Kademlia"/> as defined in <xref target="routing_table"/>. |
781 | Maintenance of the routing table (after bootstrapping) is | 781 | Maintenance of the routing table (after bootstrapping) is |
@@ -792,11 +792,11 @@ bchar = *(ALPHA / DIGIT) | |||
792 | <name>Routing Table</name> | 792 | <name>Routing Table</name> |
793 | <t> | 793 | <t> |
794 | The routing table consists of an array of k-buckets. Each | 794 | The routing table consists of an array of k-buckets. Each |
795 | k-bucket contains a list of neighbours. | 795 | k-bucket contains a list of neighbors. |
796 | The i-th k-bucket stores neighbours whose | 796 | The i-th k-bucket stores neighbors whose |
797 | identifiers are between distance 2^i and 2^(i+1) from the local peer. | 797 | identifiers are between distance 2^i and 2^(i+1) from the local peer. |
798 | System constraints will typically force an implementation to impose some | 798 | System constraints will typically force an implementation to impose some |
799 | upper limit on the number of neighbours kept per k-bucket. | 799 | upper limit on the number of neighbors kept per k-bucket. |
800 | </t> | 800 | </t> |
801 | <t> | 801 | <t> |
802 | Implementations <bcp14>SHOULD</bcp14> try to keep at least | 802 | Implementations <bcp14>SHOULD</bcp14> try to keep at least |
@@ -812,7 +812,7 @@ bchar = *(ALPHA / DIGIT) | |||
812 | If a system hits constraints with respect to | 812 | If a system hits constraints with respect to |
813 | the number of active connections, an implementation | 813 | the number of active connections, an implementation |
814 | <bcp14>MUST</bcp14> evict peers from those k-buckets with the | 814 | <bcp14>MUST</bcp14> evict peers from those k-buckets with the |
815 | largest number of neighbours. The eviction strategy <bcp14>MUST</bcp14> be | 815 | largest number of neighbors. The eviction strategy <bcp14>MUST</bcp14> be |
816 | to drop the shortest-lived connections first. | 816 | to drop the shortest-lived connections first. |
817 | </t> | 817 | </t> |
818 | </section> | 818 | </section> |
@@ -821,7 +821,7 @@ bchar = *(ALPHA / DIGIT) | |||
821 | <t> | 821 | <t> |
822 | To build its routing table, a peer will send out requests | 822 | To build its routing table, a peer will send out requests |
823 | asking for blocks of type HELLO using its own location as the key, | 823 | asking for blocks of type HELLO using its own location as the key, |
824 | but filtering all of its neighbours via the Bloom filter described | 824 | but filtering all of its neighbors via the Bloom filter described |
825 | in <xref target="result_bloomfilter"/>. | 825 | in <xref target="result_bloomfilter"/>. |
826 | These requests <bcp14>MUST</bcp14> use the FindApproximate and DemultiplexEverywhere | 826 | These requests <bcp14>MUST</bcp14> use the FindApproximate and DemultiplexEverywhere |
827 | flags. FindApproximate will ensure that other peers will reply | 827 | flags. FindApproximate will ensure that other peers will reply |
@@ -890,7 +890,7 @@ bchar = *(ALPHA / DIGIT) | |||
890 | <tt>SelectClosestpeer(K, B) -> N</tt> | 890 | <tt>SelectClosestpeer(K, B) -> N</tt> |
891 | </dt> | 891 | </dt> |
892 | <dd> | 892 | <dd> |
893 | This function selects the neighbour <tt>N</tt> from our | 893 | This function selects the neighbor <tt>N</tt> from our |
894 | routing table with the shortest XOR-distance to the key <tt>K</tt>. | 894 | routing table with the shortest XOR-distance to the key <tt>K</tt>. |
895 | This means that for all other peers <tt>N'</tt> in the routing table | 895 | This means that for all other peers <tt>N'</tt> in the routing table |
896 | <tt>GetDistance(N, K) < GetDistance(N',K)</tt>. | 896 | <tt>GetDistance(N, K) < GetDistance(N',K)</tt>. |
@@ -902,7 +902,7 @@ bchar = *(ALPHA / DIGIT) | |||
902 | </dt> | 902 | </dt> |
903 | <dd> | 903 | <dd> |
904 | This function selects a random peer <tt>N</tt> from | 904 | This function selects a random peer <tt>N</tt> from |
905 | all neighbours. | 905 | all neighbors. |
906 | Peers with a positive test in the peer Bloom | 906 | Peers with a positive test in the peer Bloom |
907 | filter <tt>B</tt> are not considered. | 907 | filter <tt>B</tt> are not considered. |
908 | </dd> | 908 | </dd> |
@@ -910,7 +910,7 @@ bchar = *(ALPHA / DIGIT) | |||
910 | <tt>Selectpeer(K, H, B) -> N</tt> | 910 | <tt>Selectpeer(K, H, B) -> N</tt> |
911 | </dt> | 911 | </dt> |
912 | <dd> | 912 | <dd> |
913 | This function selects a neighbour <tt>N</tt> depending on the | 913 | This function selects a neighbor <tt>N</tt> depending on the |
914 | number of hops <tt>H</tt> parameter. | 914 | number of hops <tt>H</tt> parameter. |
915 | If <tt>H < NETWORK_SIZE_ESTIMATE</tt> | 915 | If <tt>H < NETWORK_SIZE_ESTIMATE</tt> |
916 | this function <bcp14>MUST</bcp14> return <tt>SelectRandompeer(B)</tt> and | 916 | this function <bcp14>MUST</bcp14> return <tt>SelectRandompeer(B)</tt> and |
@@ -928,7 +928,7 @@ bchar = *(ALPHA / DIGIT) | |||
928 | <tt>ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE) -> Number</tt> | 928 | <tt>ComputeOutDegree(REPL_LVL, HOPCOUNT, L2NSE) -> Number</tt> |
929 | </dt> | 929 | </dt> |
930 | <dd> | 930 | <dd> |
931 | This function computes the number of neighbours | 931 | This function computes the number of neighbors |
932 | that a message should be forwarded to. The arguments | 932 | that a message should be forwarded to. The arguments |
933 | are the desired replication level (<tt>REPL_LVL</tt>), the <tt>HOPCOUNT</tt> of the message so far, and | 933 | are the desired replication level (<tt>REPL_LVL</tt>), the <tt>HOPCOUNT</tt> of the message so far, and |
934 | the base-2 logarithm of the current network | 934 | the base-2 logarithm of the current network |
@@ -1119,7 +1119,7 @@ bchar = *(ALPHA / DIGIT) | |||
1119 | <section anchor="p2p_hello" numbered="true" toc="default"> | 1119 | <section anchor="p2p_hello" numbered="true" toc="default"> |
1120 | <name>HelloMessage</name> | 1120 | <name>HelloMessage</name> |
1121 | <t> | 1121 | <t> |
1122 | <tt>HelloMessage</tt>s are used to inform neighbours of | 1122 | <tt>HelloMessage</tt>s are used to inform neighbors of |
1123 | a peer about the sender's available addresses. The | 1123 | a peer about the sender's available addresses. The |
1124 | recipients use these messages to inform their respective | 1124 | recipients use these messages to inform their respective |
1125 | Underlays about ways to sustain the connections and to | 1125 | Underlays about ways to sustain the connections and to |
@@ -1220,7 +1220,7 @@ bchar = *(ALPHA / DIGIT) | |||
1220 | The address information about P should then also be made | 1220 | The address information about P should then also be made |
1221 | available to each respective Underlays to enable the | 1221 | available to each respective Underlays to enable the |
1222 | Underlay to maintain optimal connectivity to the | 1222 | Underlay to maintain optimal connectivity to the |
1223 | neighbour. | 1223 | neighbor. |
1224 | </t> | 1224 | </t> |
1225 | </section> | 1225 | </section> |
1226 | </section> | 1226 | </section> |
@@ -2160,7 +2160,7 @@ gnunet+tcp://12.3.4.5/ \ | |||
2160 | does not have/require a trust anchor a priori. This is (again) in contrast | 2160 | does not have/require a trust anchor a priori. This is (again) in contrast |
2161 | to RELOAD --> | 2161 | to RELOAD --> |
2162 | <t> | 2162 | <t> |
2163 | If an upper bound to the maximum number of neighbours in a | 2163 | If an upper bound to the maximum number of neighbors in a |
2164 | k-bucket is reached, the implementation <bcp14>MUST</bcp14> | 2164 | k-bucket is reached, the implementation <bcp14>MUST</bcp14> |
2165 | prefer to preserve the oldest working connections instead of | 2165 | prefer to preserve the oldest working connections instead of |
2166 | new connections. This makes Sybil attacks less effective | 2166 | new connections. This makes Sybil attacks less effective |