commit 3b0ef33a5911b6f188c6085c310fa437733d0aa2
parent 38089ddf3f7789972b2cee1bc4ae32a85a608470
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Tue, 15 Feb 2022 14:58:39 +0100
peer vs node
Diffstat:
1 file changed, 100 insertions(+), 100 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -183,7 +183,7 @@
</dd>
<dt>Neighbour:</dt>
<dd>
- A neighbour is a node which is directly connected to our node.
+ A neighbour is a peer which is directly connected to our peer.
</dd>
<dt>Block:</dt>
<dd>
@@ -197,13 +197,13 @@
<dt>Block Storage</dt>
<dd>
The Block Storage component is used to persist and manage data
- by nodes. It includes logic for quotas, caching stragegies and
+ by peers. It includes logic for quotas, caching stragegies and
data validation.
</dd>
<dt>Responsible Peer:</dt>
<dd>
The peer <tt>N</tt> that is responsible for a specific resource <tt>K</tt>, as defined by
- the <tt>SelectClosestNode(K, N)</tt> algorithm (see <xref target="routing"/>.
+ the <tt>SelectClosestPeer(K, P)</tt> algorithm (see <xref target="routing"/>.
</dd>
<dt>Applications</dt>
<dd>
@@ -226,13 +226,13 @@
<dt>Routing</dt>
<dd>
The Routing component includes the routing table as well as
- routing and node selection logic. It facilitates the R5N routing
+ routing and peer selection logic. It facilitates the R5N routing
algorithm with required data structures and algorithms.
</dd>
<dt>Underlay Interface</dt>
<dd>
The DHT Underlay Interface is an abstraction layer on top of the
- supported links of a node. Nodes may be linked by a variety of
+ supported links of a peer. Peers may be linked by a variety of
different transports, including "classical" protocols such as
TCP, UDP and TLS or advanced protocols such as GNUnet, L2P or Tor.
</dd>
@@ -277,12 +277,12 @@ Connectivity | |Underlay| |Underlay|
<section anchor="overlay" numbered="true" toc="default">
<name>Application API</name>
<t>
- In the DHT overlay, a node is addressable by its
- <tt>Node Address</tt>.
- The <tt>Node Address</tt> is a SHA-512 hash <xref target="RFC4634"/>
- of the <tt>Node ID</tt>.
- The Node ID is the public key of the corresponding
- Ed25519<xref target="ed25519" /> node private key.
+ In the DHT overlay, a peer is addressable by its
+ <tt>Peer Address</tt>.
+ The <tt>Peer Address</tt> is a SHA-512 hash <xref target="RFC4634"/>
+ of the <tt>Peer ID</tt>.
+ The Peer ID is the public key of the corresponding
+ Ed25519<xref target="ed25519" /> peer private key.
</t>
<t>
An implementation of this specification commonly exposes the two API
@@ -427,13 +427,13 @@ Connectivity | |Underlay| |Underlay|
<section anchor="underlay" numbered="true" toc="default">
<name>Underlay</name>
<t>
- In the network underlay, a node is addressable by traditional
- means out of scope of this document. For example, the node may
+ In the network underlay, a peer is addressable by traditional
+ means out of scope of this document. For example, the peer may
have a TCP/IP address, or a HTTPS endpoint.
While the specific addressing options and mechanisms are out of scope
for this document, it is necessary to define a universal addressing
format in order to facilitate the distribution of connectivity
- information to other nodes in the DHT overlay.
+ information to other peers in the DHT overlay.
This format is the "HELLO" message.
</t>
<!--
@@ -449,17 +449,17 @@ Connectivity | |Underlay| |Underlay|
be the same keys???
3) I think we may want to mandate that the lower layer at least
- authenticate the other node (i.e. every UDP message could be in
+ authenticate the other peer (i.e. every UDP message could be in
cleartext, but would need to come with an EdDSA signature, alas 92 byte
overhead and a signature verification _required_). Otherwise, I don't
- see how we can offer even the most minimal protections against node
+ see how we can offer even the most minimal protections against peer
impersonation attacks. WDYT?
Security considerations? Prerequisites?
-->
<t>
It is expected that there are basic mechanisms available to
- manage node connectivity and addressing.
+ manage peer connectivity and addressing.
The required functionality are abstracted through the following
procedures:
</t>
@@ -468,8 +468,8 @@ Connectivity | |Underlay| |Underlay|
<tt>TRY_CONNECT(N, A)</tt>
</dt>
<dd>
- A function which allows the local node to attempt the establishment of
- a connection to another node <tt>N</tt> using an address <tt>A</tt>.
+ A function which allows the local peer to attempt the establishment of
+ a connection to another peer <tt>N</tt> using an address <tt>A</tt>.
When the connection attempt is successful, information on the new
peer is offered through the <tt>PEER_CONNECTED</tt> signal.
</dd>
@@ -491,14 +491,14 @@ Connectivity | |Underlay| |Underlay|
<tt>M = RECEIVE(P)</tt>
</dt>
<dd>
- A function or event that allows the local node to receive a protocol
+ A function or event that allows the local peer to receive a protocol
message <tt>M</tt> as defined in this document from a peer <tt>P</tt>.
</dd>
<dt>
<tt>SEND(P, M)</tt>
</dt>
<dd>
- A function that allows the local node to send a protocol message
+ A function that allows the local peer to send a protocol message
<tt>M</tt> as defined in this document to a peer <tt>P</tt>.
If call to SEND fails, the message has not been sent.
</dd>
@@ -582,7 +582,7 @@ Connectivity | |Underlay| |Underlay|
active addresses in a HELLO block <xref target="hello_block"/>.
</t>
<t>
- In order to find more close nodes in the network, an
+ In order to find more close peers in the network, an
implementation MUST now periodically <xref target="find_peer"/> messages.
</t>
<t>
@@ -593,7 +593,7 @@ Connectivity | |Underlay| |Underlay|
</t>
<t>
Any implementation encountering a HELLO GET request initially
- sends its own node address if it.
+ sends its own peer address if it.
</t>
</section>
<section anchor="routing" numbered="true" toc="default">
@@ -601,17 +601,17 @@ Connectivity | |Underlay| |Underlay|
<section anchor="peer_storage">
<name>Peer Storage</name>
<t>
- A R5N implementation must store the information on connected nodes
+ A R5N implementation must store the information on connected peers
and update changes accordingly in a local persistance component such
as a database.
Upon receiving a connection notification from the Underlay through
- <tt>NODE_CONNECTED</tt>, information on the new peer is added to the
+ <tt>PEER_CONNECTED</tt>, information on the new peer is added to the
local peer storage.
When disconnect is indicated by the Underlay through
- <tt>NODE_DISCONNECTED</tt> the peer MUST be removed from the local
+ <tt>PEER_DISCONNECTED</tt> the peer MUST be removed from the local
peer storage.
In order to achieve O(log n) routing performance,
- the data structure for managing connected nodes and their
+ the data structure for managing connected peers and their
metadata MUST be implemented using the k-buckets concept of
<xref target="Kademlia"/> as defined in <xref target="routing_table"/>.
</t>
@@ -645,17 +645,17 @@ Connectivity | |Underlay| |Underlay|
<!-- FIXME: CG: I think this last one is not implemented! -->
<!-- FIXME: CG: I also suspect we need to review how the block API filters HELLOs, to NOT use the full body / expiration time in the hash -->
These requests MUST use the FindApproximate and DemultiplexEverywhere
- options. FindApproximate will ensure that other nodes will reply
+ options. FindApproximate will ensure that other peers will reply
with keys they merely consider close-enough, while DemultiplexEverywhere
will cause each peer on the path to respond, which is likely to yield
HELLOs of peers that are useful somewhere in the routing table.
</t>
<t>
To facilitate peer discovery, each peer MUST broadcast its own
- HELLO data to all nodes in the routing table periodically.
+ HELLO data to all peers in the routing table periodically.
<!-- FIXME: CG: specify frequency? -->
- Whenever a peer receives such a HELLO message from another node,
- it must cache it as long as that node is in its routing table
+ Whenever a peer receives such a HELLO message from another peer,
+ it must cache it as long as that peer is in its routing table
(or until the HELLO expires) and serve it in response to
Peer Discovery requests. Details about the format of the
HELLO message are given in section p2p_hello_wire.
@@ -664,31 +664,31 @@ Connectivity | |Underlay| |Underlay|
<section anchor="routing_table">
<name>Routing Table</name>
<t>
- In order to select nodes which are suitable destinations for
+ In order to select peers which are suitable destinations for
routing messages, R5N uses a hybrid approach:
- Given an estimated network size N, the node selection for the
- first N hops is random. After the initial N hops, node selection
- follows an XOR-based node distance calculation.
+ Given an estimated network size N, the peer selection for the
+ first N hops is random. After the initial N hops, peer selection
+ follows an XOR-based peer distance calculation.
</t>
<t>
- The routing table consists of an array of lists of connected nodes.
+ The routing table consists of an array of lists of connected peers.
The i-th list stores neighbours whose identifiers are between
- distance 2^i 2^(i+1) from the local node.
+ distance 2^i 2^(i+1) from the local peer.
An implementation MAY choose an upper limit on the length of the
lists, but SHOULD try to keep at least 5 entries per bucket.
For example, in case of system constraints with respect to active
- connections, an implementation SHOULD evict nodes in large buckets
- rather than nodes from shallow ones.
+ connections, an implementation SHOULD evict peers in large buckets
+ rather than peers from shallow ones.
</t>
<t>
As the message traverses a random path through the network for the
first N hops, it is essential that routing loops are avoided.
In R5N, a bloomfilter is used as part of the routing metadata in
messages. The bloomfilter is updates at each hop with the hops
- node identity.
+ peer identity.
For the next hop selection in both the random and the deterministic
- case, any node which is in the bloomfilter for the respective message
- is not included in the node selection process.
+ case, any peer which is in the bloomfilter for the respective message
+ is not included in the peer selection process.
</t>
<t>
The R5N routing component MUST implement the following functions:
@@ -703,41 +703,41 @@ Connectivity | |Underlay| |Underlay|
the leftmost bit is the most significant bit.
</dd>
<dt>
- <tt>SelectClosestNode(K, B) -> N</tt>
+ <tt>SelectClosestpeer(K, B) -> N</tt>
</dt>
<dd>
- This function selects the connected node <tt>N</tt> from our
+ This function selects the connected peer <tt>N</tt> from our
routing table with the shortest XOR-distance to the key <tt>K</tt>.
- This means that for all other nodes <tt>N'</tt> in the routing table
+ This means that for all other peers <tt>N'</tt> in the routing table
<tt>GetDistance(N, K) < GetDistance(N',K)</tt>.
- Nodes in the bloomfilter <tt>B</tt> are not considered.
+ peers in the bloomfilter <tt>B</tt> are not considered.
</dd>
<dt>
- <tt>SelectRandomNode(B) -> N</tt>
+ <tt>SelectRandompeer(B) -> N</tt>
</dt>
<dd>
- This function selects a random node <tt>N</tt> from all connected
- nodes.
- Nodes in the bloomfilter <tt>B</tt> are not considered.
+ This function selects a random peer <tt>N</tt> from all connected
+ peers.
+ peers in the bloomfilter <tt>B</tt> are not considered.
</dd>
<dt>
- <tt>SelectNode(K, H, B) -> N</tt>
+ <tt>Selectpeer(K, H, B) -> N</tt>
</dt>
<dd>
- This function selects a node <tt>N</tt> depending on the
+ This function selects a peer <tt>N</tt> depending on the
number of hops <tt>H</tt> parameter.
If <tt>H < NETWORK_SIZE_ESTIMATE</tt>
- this function MUST return <tt>SelectRandomNode()</tt> and
- <tt>SelectClosestnode(K)</tt> otherwise.
- Nodes in the bloomfilter <tt>B</tt> are not considered.
+ this function MUST return <tt>SelectRandompeer()</tt> and
+ <tt>SelectClosestpeer(K)</tt> otherwise.
+ peers in the bloomfilter <tt>B</tt> are not considered.
</dd>
<dt>
- <tt>IsClosestNode(N, K, B) -> true | false</tt>
+ <tt>IsClosestpeer(N, K, B) -> true | false</tt>
</dt>
<dd>
- checks if <tt>N</tt> is the closest node for <tt>K</tt>
- (cf. <tt>SelectClosestNode(K)</tt>).
- Nodes in the bloomfilter <tt>B</tt> are not considered.
+ checks if <tt>N</tt> is the closest peer for <tt>K</tt>
+ (cf. <tt>SelectClosestpeer(K)</tt>).
+ peers in the bloomfilter <tt>B</tt> are not considered.
</dd>
</dl>
</section>
@@ -750,7 +750,7 @@ Connectivity | |Underlay| |Underlay|
the peer <tt>P</tt>.
In the following, the wire formats of the messages and the required
processing are detailed.
- The local node address is referred to as <tt>N</tt>.
+ The local peer address is referred to as <tt>N</tt>.
</t>
<section anchor="route_options">
<name>Route Options</name>
@@ -765,7 +765,7 @@ Connectivity | |Underlay| |Underlay|
<dl>
<dt>0: Demultiplex-Everywhere</dt>
<dd>
- indicates that each node along the way should process the request.
+ indicates that each peer along the way should process the request.
</dd>
<dt>1: Record-Route</dt>
<dd>
@@ -967,7 +967,7 @@ Connectivity | |Underlay| |Underlay|
</dd>
<dt>PEER_BF</dt>
<dd>
- A bloomfilter (for node addresses) to stop circular routes.
+ A bloomfilter (for peer addresses) to stop circular routes.
</dd>
<dt>BLOCK_KEY</dt>
<dd>
@@ -977,7 +977,7 @@ Connectivity | |Underlay| |Underlay|
<dt>PUTPATH</dt>
<dd>
the variable-length PUT path.
- The path consists of a list of PATH_LEN node addresses.
+ The path consists of a list of PATH_LEN peer addresses.
</dd>
<dt>BLOCK</dt>
<dd>
@@ -1011,17 +1011,17 @@ Connectivity | |Underlay| |Underlay|
it MUST be discarded.
</li>
<li>
- The node address of the sender peer <tt>P</tt> SHOULD be in <tt>PEER_BF</tt>.
+ The peer address of the sender peer <tt>P</tt> SHOULD be in <tt>PEER_BF</tt>.
If not, the implementation MAY log an error, but MUST continue.
</li>
<li>
If the <tt>RecordRoute</tt> flag is set in OPTIONS,
- the local node address MUST be appended to the <tt>PUTPATH</tt>
+ the local peer address MUST be appended to the <tt>PUTPATH</tt>
of the message.
</li>
<li>
- If the local node is the closest node
- (cf. <tt>IsClosestNode(N, BLOCK_KEY)</tt>) or the <tt>DemultiplexEverywhere</tt>
+ If the local peer is the closest peer
+ (cf. <tt>IsClosestpeer(N, BLOCK_KEY)</tt>) or the <tt>DemultiplexEverywhere</tt>
options flag ist set, the message MUST
be stored locally in the block storage.
</li>
@@ -1032,9 +1032,9 @@ Connectivity | |Underlay| |Underlay|
number of peers to forward the message to. The implementation MAY
forward to fewer or no peers in order to handle resource constraints
such as bandwidth.
- Finally, the local node address MUST be added to the
+ Finally, the local peer address MUST be added to the
<tt>PEER_BF</tt> of the forwarded message.
- For all peers with node address <tt>P</tt> chosen to forward the message
+ For all peers with peer address <tt>P</tt> chosen to forward the message
to, <tt>SEND(P, PutMessage)</tt> is called.
</li>
</ol>
@@ -1103,7 +1103,7 @@ Connectivity | |Underlay| |Underlay|
</dd>
<dt>PEER_BF</dt>
<dd>
- A bloomfilter (for node identities) to stop circular routes.
+ A bloomfilter (for peer identities) to stop circular routes.
</dd>
<dt>QUERY_HASH</dt>
<dd>
@@ -1146,14 +1146,14 @@ Connectivity | |Underlay| |Underlay|
the message MUST be discarded.
</li>
<li>
- The node address of the sender peer <tt>P</tt> SHOULD be in the
+ The peer address of the sender peer <tt>P</tt> SHOULD be in the
PEER_BF bloom filter. If not, the
implementation MAY log an error, but MUST continue.
</li>
<li>
<t>
- If the local node is the closest node
- (cf. <tt>IsClosestNode (N, QueryHash)</tt>) or the
+ If the local peer is the closest peer
+ (cf. <tt>IsClosestpeer (N, QueryHash)</tt>) or the
<tt>DemultiplexEverywhere</tt> options flag is set, a reply
MUST be produced (if one is available) using the following
steps:
@@ -1192,15 +1192,15 @@ Connectivity | |Underlay| |Underlay|
<tt>BTYPE</tt>
</li>
<li>
- Given the value in REPL_LVL, the number of nodes to forward to
- MUST be calculated (NUM-FORWARD-nodeS). If there is at least one
- node to forward to, the implementation SHOULD select up to this
- number of nodes to forward the message to. The implementation MAY
- forward to fewer or no nodes in order to handle resource constraints
+ Given the value in REPL_LVL, the number of peers to forward to
+ MUST be calculated (NUM-FORWARD-peerS). If there is at least one
+ peer to forward to, the implementation SHOULD select up to this
+ number of peers to forward the message to. The implementation MAY
+ forward to fewer or no peers in order to handle resource constraints
such as bandwidth.
The message bloom filter PEER_BF MUST be updated with the local
- node address <tt>N</tt>.
- For all peers with node address <tt>P'</tt> chosen to forward the message
+ peer address <tt>N</tt>.
+ For all peers with peer address <tt>P'</tt> chosen to forward the message
to, <tt>SEND(P', PutMessage)</tt> is called.
</li>
</ol>
@@ -1281,12 +1281,12 @@ Connectivity | |Underlay| |Underlay|
<dt>PUTPATH</dt>
<dd>
the variable-length PUT path.
- The path consists of a list of PATH_LEN node addresses.
+ The path consists of a list of PATH_LEN peer addresses.
</dd>
<dt>GETPATH</dt>
<dd>
the variable-length PUT path.
- The path consists of a list of PATH_LEN node addresses.
+ The path consists of a list of PATH_LEN peer addresses.
</dd>
<dt>BLOCK</dt>
<dd>
@@ -1298,7 +1298,7 @@ Connectivity | |Underlay| |Underlay|
<section anchor="p2p_result_processing">
<name>Processing</name>
<t>
- Upon receiving a <tt>ResultMessage</tt> from a connected node.
+ Upon receiving a <tt>ResultMessage</tt> from a connected peer.
An implementation MUST process it step by step as follows:
</t>
<ol>
@@ -1310,12 +1310,12 @@ Connectivity | |Underlay| |Underlay|
If the MTYPE of the message indicates a HELLO block, it
must be validated according to <xref target="hello_block"/>.
The payload MUST be considered for the local routing table by
- trying to establish a connection to the node using the information
+ trying to establish a connection to the peer using the information
from the HELLO block. If a connection can be established,
- the node is added to the <tt>KBuckets</tt> routing table.
+ the peer is added to the <tt>KBuckets</tt> routing table.
</li>
<li>
- If the sender node of the message is already found in the
+ If the sender peer of the message is already found in the
GETPATH, the path MUST be truncated at this position.
The implementation MAY log a warning in such a case.
</li>
@@ -1335,7 +1335,7 @@ Connectivity | |Underlay| |Underlay|
</li>
<li>
<t>
- If requests by other nodes for this QUERY_HASH or BTYPE are
+ If requests by other peers for this QUERY_HASH or BTYPE are
known,
the result block is validated against each request using
the respective <tt>ValidateBlockReply</tt> function.
@@ -1353,7 +1353,7 @@ Connectivity | |Underlay| |Underlay|
</t>
<t>
For each pending request the reply is routed to the requesting
- peer <tt>P'</tt>. <!--FIXME routed to node or forwarded to peer?-->
+ peer <tt>P'</tt>. <!--FIXME routed to peer or forwarded to peer?-->
</t>
</li>
</ol>
@@ -1414,7 +1414,7 @@ Connectivity | |Underlay| |Underlay|
is used to evaluate a block including its <tt>Key</tt> and payload.
It is used as part <tt>ResultMessage</tt> processing.
The validation of the respective <tt>Block</tt> requires a pending local query
- or a previously routed request of another node and its associated
+ or a previously routed request of another peer and its associated
XQuery data and Key.
The validation MUST include a check of the block payload against the
key under which it is requested to be stored.
@@ -1422,7 +1422,7 @@ Connectivity | |Underlay| |Underlay|
<dt>DeriveBlockKey(Block) -> Key</dt>
<dd>
is used to synthesize the block key from the block payload
- and metadata. It is used as part of FIND-node message processing.
+ and metadata. It is used as part of FIND-peer message processing.
</dd>
<dt>FilterResult(Block, XQuery, Key) -> ReplyEvaluationResult</dt>
<dd>
@@ -1440,13 +1440,13 @@ Connectivity | |Underlay| |Underlay|
<t>
Applications can and should define their own block types.
The block type determines the format and handling of the block
- payload by nodes in PUT and RESULT messages.
+ payload by peers in PUT and RESULT messages.
Block types MUST be registered with GANA <xref target="gana"/>.
</t>
<t>
- For bootstrapping and node discovery, the DHT implementation uses
+ For bootstrapping and peer discovery, the DHT implementation uses
its own block type called "HELLO". A block with this block type
- contains the NodeID of the node initiating the GET request.
+ contains the peerID of the peer initiating the GET request.
</t>
<section anchor="hello_block">
<name>HELLO</name>
@@ -1485,7 +1485,7 @@ Connectivity | |Underlay| |Underlay|
<dl>
<dt>PEER-ID</dt>
<dd>
- is the Peer-ID of the node which has generated this HELLO.
+ is the Peer-ID of the peer which has generated this HELLO.
</dd>
<dt>SIGNATURE</dt>
<dd>
@@ -1561,12 +1561,12 @@ Connectivity | |Underlay| |Underlay|
</t>
<t>
A HELLO reply block MAY be empty. Otherwise, it contains the
- HELLO of a node.
+ HELLO of a peer.
</t>
<t>
The <tt>ADDRESSES</tt> part of the <tt>HELLO</tt> indicate endpoints
which can be used by the Underlay in order to establish a connection
- with the node identified by <tt>Peer-ID</tt>.
+ with the peer identified by <tt>Peer-ID</tt>.
An example of an addressing scheme used throughout
this document is "ip+tcp", which refers to a standard TCP/IP socket
connection. The "hier"-part of the URI must provide a suitable
@@ -1593,10 +1593,10 @@ gnunet+tcp://12.3.4.5/ \
However, the lower bound MUST be adhered to. <!-- FIXME define somewhere-->
If there is a limit to the maximum number of neighbours in a
k-bucket, the implementation must be careful when choosing the
- which nodes to replace:
+ which peers to replace:
For example, a simple optimization of the peer selection algorithm may
- be to oder all nodes within the k-bucket by distance and evict the
- nodes which are the farthest away.
+ be to oder all peers within the k-bucket by distance and evict the
+ peers which are the farthest away.
However, this is not a good idea from a resilience perspective.
It is much more important to preserve older connections than closer
ones.
@@ -1641,7 +1641,7 @@ Number| Name | Contact | References | Description
------+--------+---------+------------+-------------------------
0 ANY N/A [This.I-D] Reserved
7 HELLO N/A [This.I-D] Type of a block that contains
- a HELLO for a node
+ a HELLO for a peer
11 GNS N/A GNS Block for storing record data
]]></artwork>
</figure>
