[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lsd0004] branch master updated: peer vs node
|
From: |
gnunet |
|
Subject: |
[lsd0004] branch master updated: peer vs node |
|
Date: |
Fri, 31 Dec 2021 13:40:18 +0100 |
This is an automated email from the git hooks/post-receive script.
martin-schanzenbach pushed a commit to branch master
in repository lsd0004.
The following commit(s) were added to refs/heads/master by this push:
new 309aadb peer vs node
309aadb is described below
commit 309aadbf12f0a89eea88e7de2e74cf2077bdaee5
Author: Martin Schanzenbach <schanzen@gnunet.org>
AuthorDate: Fri Dec 31 13:40:14 2021 +0100
peer vs node
---
draft-schanzen-r5n.xml | 240 +++++++++++++++++++++++++------------------------
1 file changed, 121 insertions(+), 119 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
index 3e9a86c..7219a26 100644
--- a/draft-schanzen-r5n.xml
+++ b/draft-schanzen-r5n.xml
@@ -186,7 +186,7 @@ Connectivity | |Underlay| |Underlay|
<dt>Block Storage</dt>
<dd>
The Block Storage component is used to persist and manage data
- by peers. It includes logic for quotas, caching stragegies and
+ by nodes. It includes logic for quotas, caching stragegies and
data validation.
</dd>
<dt>Message Processing</dt>
@@ -197,13 +197,13 @@ Connectivity | |Underlay| |Underlay|
<dt>Routing</dt>
<dd>
The Routing component includes the routing table as well as
- routing and peer selection logic. It facilitates the R5N routing
+ routing and node 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 peer. Peers may be linked by a variety of
+ supported links of a node. Nodes 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>
@@ -212,10 +212,12 @@ Connectivity | |Underlay| |Underlay|
<section anchor="overlay" numbered="true" toc="default">
<name>Overlay</name>
<t>
- In the DHT overlay, a peer is addressable by its Peer ID.
- The Peer ID is the 256-bit hash of the peer public key.
- The peer public key is the public key of the corresponding
- Ed25519<xref target="ed25519" /> peer private key.
+ In the DHT overlay, a node is addressable by its <tt>NodeID</tt>.
+ The <tt>NodeID</tt> is a 512-bit hash of the <tt>NodeKey</tt>.
+ <!-- FIXME should the node ID be agile? Should the signature then
+ also be agile?-->
+ <!--The node public key is the public key of the corresponding
+ Ed25519<xref target="ed25519" /> node private key.-->
</t>
<t>
Any implementation of this specification MUST expose the two API
@@ -266,16 +268,16 @@ GET(Key[, GetParams]) -> Results as List
<dl anchor="route_options">
<dt>DemultiplexEverywhere</dt>
<dd>
- indicates that each peer along the way should process the request.
+ indicates that each node along the way should process the request.
</dd>
<dt>RecordRoute</dt>
<dd>
indicates to keep track of the route that the message takes
in the P2P network.
</dd>
- <dt>FindPeer</dt>
+ <dt>FindNode</dt>
<dd>
- indicates that this is a request used to find additional peers.
+ indicates that this is a request used to find additional nodes.
This is a special flag which modifies the message processing to
allow approximate results.
</dd>
@@ -326,13 +328,13 @@ PUT(Key, Block, BlockType[, PutParams])
<section anchor="underlay" numbered="true" toc="default">
<name>Underlay</name>
<t>
- In the network underlay, a peer is addressable by traditional
- means out of scope of this document. For example, the peer may
+ In the network underlay, a node is addressable by traditional
+ means out of scope of this document. For example, the node 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 peers in the DHT overlay.
+ information to other nodes in the DHT overlay.
This format is the "HELLO" message.
</t>
@@ -349,57 +351,57 @@ PUT(Key, Block, BlockType[, PutParams])
be the same keys???
3) I think we may want to mandate that the lower layer at least
-authenticate the other peer (i.e. every UDP message could be in
+authenticate the other node (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 peer
+see how we can offer even the most minimal protections against node
impersonation attacks. WDYT?
Security considerations? Prerequisites?
-->
<t>
It is expected that there are basic mechanisms available to
- manage peer connectivity and addressing.
+ manage node connectivity and addressing.
The required functionality are abstracted through the following
procedures and events:
</t>
<dl>
- <dt>PEER_CONNECTED(phash,address)</dt>
+ <dt>NODE_CONNECTED(NodeID, Address)</dt>
<dd>
- is a signal that allows the DHT to react to peers which connect.
+ is a signal that allows the DHT to react to nodes which connect.
Such an event triggers, for example, updates in the
routing table.
</dd>
- <dt>PEER_DISCONNECTED(phash,address)</dt>
+ <dt>NODE_DISCONNECTED(NodeID, Address)</dt>
<dd>
- is a signal that allows the DHT to react to peers which disconnect.
+ is a signal that allows the DHT to react to nodes which disconnect.
Such an event triggers, for example, updates in the
routing table.
</dd>
- <dt>TRY_CONNECT(pid, address)</dt>
+ <dt>TRY_CONNECT(NodeID, Address)</dt>
<dd>
- A function which allows a peer to attempt the establishment of
- a connection to another peer using an address.
+ A function which allows a node to attempt the establishment of
+ a connection to another node using an address.
</dd>
- <dt>HOLD(pash)</dt>
+ <dt>HOLD(NodeID)</dt>
<dd>
A function which tells the underlay to keep a hold on the connection
- to another peer.
+ to another node.
</dd>
- <dt>DROP(pash)</dt>
+ <dt>DROP(NodeID)</dt>
<dd>
A function which tells the underlay to drop the connection to another
- peer.
+ node.
</dd>
- <dt>RECEIVE(source, message)</dt>
+ <dt>RECEIVE(NodeID, Message)</dt>
<dd>
- A function or event that allows the peer to receive protocol
- messages as defined in this document from a connected peer.
+ A function or event that allows the node to receive protocol
+ messages as defined in this document from a connected node.
</dd>
- <dt>SEND(target, message)</dt>
+ <dt>SEND(NodeID, Message)</dt>
<dd>
- A function that allows a peer to send protocol messages as defined
- in this document to a connected peer. If call to SEND fails,
+ A function that allows a node to send protocol messages as defined
+ in this document to a connected node. If call to SEND fails,
the message has not been sent.
</dd>
<dt>NETWORK_SIZE_ESTIMATE(N)</dt>
@@ -407,13 +409,13 @@ see how we can offer even the most minimal protections
against peer
A function or event that provides estimates on the network size
for use in the DHT routing algorithms.
</dd>
- <dt>ADDRESS_ADD(pk, address)</dt>
+ <dt>ADDRESS_ADD(NodeID, address)</dt>
<dd>
The underlay signals us that an address was added.
This information is used, for example, to publish
connectivity as part of the bootstrapping and overlay creation.
</dd>
- <dt>ADDRESS_DELETE(pk, address)</dt>
+ <dt>ADDRESS_DELETE(NodeID, address)</dt>
<dd>
The underlay signals us that an address was removed.
This information is used, for example, to publish
@@ -450,46 +452,46 @@ see how we can offer even the most minimal protections
against peer
<section anchor="routing_table">
<name>Routing Table</name>
<t>
- R5N stores the information of all connected peers in a a set of lists
+ R5N stores the information of all connected nodes in a a set of lists
similar to the k-buckets data structure of <xref target="Kademlia"/>.
- The size of this set is determined by the number of connected peers.
+ The size of this set is determined by the number of connected nodes.
A k-bucket contains a list of connected node IDs which share the same
- bit prefix length with the local <tt>PeerID</tt>.
+ bit prefix length with the local <tt>nodeID</tt>.
This number is called the <tt>index</tt> of the k-bucket.
The index which determines in which of the k-buckets to add a given
- peer is calculated using the <tt>FindBucket</tt> procedure.
+ node is calculated using the <tt>FindBucket</tt> procedure.
</t>
<t>
- In order to select peers from the routing table which are suitable
+ In order to select nodes from the routing table which are suitable
destinations for sending messages, R5N uses a hybrid approach:
- 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.
+ 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.
</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
- peer identity.
+ node identity.
For the next hop selection in both the random and the deterministic
- case, any peer which is in the bloomfilter for the respective message
- is not included in the peer selection process.
+ case, any node which is in the bloomfilter for the respective message
+ is not included in the node selection process.
</t>
<!-- Fixme: We may want to propose our modified, optimized XOR metric
here or reference Kademlia -->
<t>
The buckets serve implicitly as a routing table for messages by
calculating the shortest distance from a message key to node ID.
- In order to select a peer for a given message key and bloomfilter,
- the <tt>PEER-SELECT</tt> is used (see <xref target="peer-select"/>.
+ In order to select a node for a given message key and bloomfilter,
+ the <tt>node-select</tt> is used (see <xref target="node-select"/>.
</t>
- <figure anchor="peer-select">
+ <figure anchor="node-select">
<artwork name="" type="" align="left" alt=""><![CDATA[
-PEER-SELECT(key, bloomfilter)
- peers := <Select all known peers NOT in message bloomfilter>
+node-SELECT(key, bloomfilter)
+ nodes := <Select all known peers NOT in message bloomfilter>
IF hops >= N
dist := MAX_VALUE
- FOR EACH p IN peers
+ FOR EACH p IN nodes
IF XOR(p, key) < dist
dist := XOR(p, key)
target := p
@@ -497,7 +499,7 @@ PEER-SELECT(key, bloomfilter)
END
ELSE
r := rand()
- target := peers[r]
+ target := nodes[r]
END
END
]]></artwork>
@@ -507,36 +509,36 @@ END
the R5N routing component MUST implement the following functions:
</t>
<dl>
- <dt><tt>FindBucket(PeerID, Key) -> k-bucket as List</tt></dt>
+ <dt><tt>FindBucket(NodeID, Key) -> k-bucket as List</tt></dt>
<dd>
The <tt>FindBucket</tt> function determines how many low
- order bits succesively match between a <tt>PeerID</tt> and a
+ order bits succesively match between a <tt>nodeID</tt> and a
<tt>Key</tt> starting from the first bit. The procedure returns
the k-bucket for this index.
</dd>
- <dt><tt>GetDistance(NodeKey_A, NodeKey_B) -> Distance as
Integer</tt></dt>
+ <dt><tt>GetDistance(NodeID_A, NodeID_B) -> Distance as
Integer</tt></dt>
<dd>
FIXME: We do NOT do XOR here. We do some kind of
fancy calculation. See get_distance()
</dd>
- <dt><tt>SelectClosestPeer(Key) -> NodeID</tt></dt>
+ <dt><tt>SelectClosestNode(Key) -> NodeID</tt></dt>
<dd>
This function determines the closest node ID to <tt>Key</tt>
of all connected nodes using <tt>GetDistance</tt>.
FIXME: Also has a bloomfilter. Isn't AmClosestNode simply
- !SelectClosestPeer == myID ?
+ !SelectClosestnode == myID ?
</dd>
- <dt><tt>SelectRandomPeer() -> NodeID</tt></dt>
+ <dt><tt>SelectRandomnode() -> NodeID</tt></dt>
<dd>
This function selects a random node ID from all connected
nodes. FIXME find elegant way to handle bloomfilter
</dd>
- <dt><tt>SelectPeer(Key, NumberOfHops)</tt></dt>
+ <dt><tt>Selectnode(Key, NumberOfHops)</tt></dt>
<dd>
- This function selects a peer depending on the <tt>NumberOfHops</tt>
+ This function selects a node depending on the <tt>NumberOfHops</tt>
Parameter. If <tt>NumberOfHops < NETWORK_SIZE_ESTIMATE</tt>
- this function returns <tt>SelectRandomPeer()</tt> and
- <tt>SelectClosestPeer(Key)</tt> otherwise.
+ this function returns <tt>SelectRandomnode()</tt> and
+ <tt>SelectClosestnode(Key)</tt> otherwise.
</dd>
<dt><tt>AmClosestNode(NodeID, Key, Bloom) -> true | false</tt></dt>
<dd>
@@ -546,7 +548,7 @@ END
If there is a node ID <tt>NodeID'</tt> in the k-bucket where
<tt>GetDistance(NodeID, Key) > GetDistance(NodeID', Key)</tt>,
then <tt>false</tt> is returned, otherwise <tt>true</tt>.
- FIXME: Currently, GDS_am_closest_peer checks for longer matching
+ FIXME: Currently, GDS_am_closest_node checks for longer matching
bits. Not GetDistance. Why?
</dd>
</dl>
@@ -559,7 +561,7 @@ END
<t>
In order to prevent circular routes, GET and PUT messages contain
a 128-bit Bloom filter (m=128). The Bloom filter is used to detect
duplicate
- peer IDs along the route.
+ node IDs along the route.
A Bloom filter "bf" is initially empty, consisting only of zeroes.
There are two functions which can be invoked on the Bloom filter:
BF-SET(bf, e) and BF-TEST(bf, e) where "e" is an element which is to
added
@@ -667,7 +669,7 @@ END
</dd>
<dt>BLOOMFILTER</dt>
<dd>
- A bloomfilter (for peer identities) to stop circular routes.
+ A bloomfilter (for node identities) to stop circular routes.
</dd>
<dt>KEY</dt>
<dd>
@@ -677,7 +679,7 @@ END
<dt>PUTPATH</dt>
<dd>
the variable-length PUT path.
- The path consists of a list of PATH_LEN peer IDs.
+ The path consists of a list of PATH_LEN node IDs.
</dd>
<dt>BLOCK</dt>
<dd>
@@ -689,7 +691,7 @@ END
<section anchor="p2p_put_processing">
<name>Processing</name>
<t>
- Upon receiving a <tt>PutMessage</tt> from a connected peer.
+ Upon receiving a <tt>PutMessage</tt> from a connected node.
An implementation MUST process it step by step as follows:
</t>
<ol>
@@ -710,26 +712,26 @@ END
it MUST be discarded.
</li>
<li>
- The sender peer ID SHOULD be in the BLOOMFILTER. If not, the
+ The sender node ID SHOULD be in the BLOOMFILTER. 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 peer
ID
+ If the <tt>RecordRoute</tt> flag is set in OPTIONS, the local node
ID
MUST be appended to the <tt>PUTPATH</tt> of the message.
</li>
<li>
- If the local peer is the closest peer (<tt>AM-CLOSEST-PEER</tt> is
true) or the
+ If the local node is the closest node (<tt>AM-CLOSEST-NODE</tt> is
true) or the
<tt>DemultiplexEverywhere</tt> options flag ist set, the message
MUST
be stored locally in the block storage.
</li>
<li>
- 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
+ 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
such as bandwidth.
- The message BLOOMFILTER MUST be updated with the local peer ID.
+ The message BLOOMFILTER MUST be updated with the local node ID.
</li>
</ol>
</section>
@@ -798,7 +800,7 @@ END
</dd>
<dt>BLOOMFILTER</dt>
<dd>
- A bloomfilter (for peer identities) to stop circular routes.
+ A bloomfilter (for node identities) to stop circular routes.
</dd>
<dt>KEY</dt>
<dd>
@@ -822,7 +824,7 @@ END
<section anchor="p2p_get_processing">
<name>Processing</name>
<t>
- Upon receiving a <tt>GetMmessage</tt> from a connected peer an
+ Upon receiving a <tt>GetMmessage</tt> from a connected node an
implementation MUST process it step by step as follows:
</t>
<ol>
@@ -835,18 +837,18 @@ END
the message MUST be discarded.
</li>
<li>
- The sender peer ID SHOULD be in the BLOOMFILTER. If not, the
+ The sender node ID SHOULD be in the BLOOMFILTER. If not, the
implementation MAY log an error, but MUST continue.
</li>
<li>
<t>
- If the local peer is the closest peer (AM-CLOSEST-PEER) or the
+ If the local node is the closest node (AM-CLOSEST-NODE) or the
<tt>DemultiplexEverywhere</tt> options flag is set, a reply
MUST be produced:
</t>
<ol>
<li>
- If OPTIONS indicate a <tt>FindPeer</tt> request, FIXME the
peer selection
+ If OPTIONS indicate a <tt>Findnode</tt> request, FIXME the
node selection
foo from buckets that probably needs fixing. Take into account
<tt>REPLY_BF</tt>
</li>
@@ -864,13 +866,13 @@ END
<tt>BTYPE</tt>
</li>
<li>
- 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
+ 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
such as bandwidth.
- The message BLOOMFILTER MUST be updated with the local peer ID.
+ The message BLOOMFILTER MUST be updated with the local node ID.
</li>
</ol>
</section>
@@ -950,12 +952,12 @@ END
<dt>PUTPATH</dt>
<dd>
the variable-length PUT path.
- The path consists of a list of PATH_LEN peer IDs.
+ The path consists of a list of PATH_LEN node IDs.
</dd>
<dt>GETPATH</dt>
<dd>
the variable-length PUT path.
- The path consists of a list of PATH_LEN peer IDs.
+ The path consists of a list of PATH_LEN node IDs.
</dd>
<dt>BLOCK</dt>
<dd>
@@ -967,7 +969,7 @@ END
<section anchor="p2p_result_processing">
<name>Processing</name>
<t>
- Upon receiving a <tt>ResultMessage</tt> from a connected peer.
+ Upon receiving a <tt>ResultMessage</tt> from a connected node.
An implementation MUST process it step by step as follows:
</t>
<ol>
@@ -979,12 +981,12 @@ END
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 peer using the information
+ trying to establish a connection to the node using the information
from the HELLO block. If a connection can be established,
- the peer is added to the <tt>KBuckets</tt> routing table.
+ the node is added to the <tt>KBuckets</tt> routing table.
</li>
<li>
- If the sender peer of the message is already found in the
+ If the sender node 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>
@@ -1002,12 +1004,12 @@ END
</li>
<li>
<t>
- If requests by other peers for this KEY or BTYPE are known,
+ If requests by other nodes for this KEY or BTYPE are known,
the result block is validated against each request using
the respective <tt>ValidateBlockReply</tt> function.
</t>
<t>
- If the request options include <tt>FindPeer</tt> and the result
+ If the request options include <tt>Findnode</tt> and the result
message block type is HELLO the block validation must use the
key derived using <tt>DeriveBlockKey</tt> as the key included in
the request is only approximate. (FIXME: So we extract the key
@@ -1020,7 +1022,7 @@ END
</t>
<t>
For each pending request the reply is sent to the requesting
- peer.
+ node.
</t>
</li>
</ol>
@@ -1080,7 +1082,7 @@ END
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 peer and its associated
+ or a previously routed request of another node 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.
@@ -1088,7 +1090,7 @@ END
<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-PEER message processing.
+ and metadata. It is used as part of FIND-node message processing.
</dd>
<dt>FilterResult(Block, XQuery, Key) -> ReplyEvaluationResult</dt>
<dd>
@@ -1106,13 +1108,13 @@ END
<t>
Applications can and should define their own block types.
The block type determines the format and handling of the block
- payload by peers in PUT and RESULT messages.
+ payload by nodes in PUT and RESULT messages.
Block types MUST be registered with GANA <xref target="gana"/>.
</t>
<t>
- For bootstrapping and peer discovery, the DHT implementation uses
+ For bootstrapping and node discovery, the DHT implementation uses
its own block type called "HELLO". A block with this block type
- contains the peer ID of the peer initiating the GET request.
+ contains the NodeID of the node initiating the GET request.
</t>
<section anchor="hello_block">
<name>HELLO</name>
@@ -1127,7 +1129,7 @@ END
<artwork name="" type="" align="left" alt=""><![CDATA[
0 8 16 24 32 40 48 56
+-----+-----+-----+-----+-----+-----+-----+-----+
-| TYPE | SIZE | NODEID /
+| TYPE | SIZE | NODEKEY /
+-----+-----+-----+-----+ (variable length) /
/ /
+-----+-----+-----+-----+-----+-----+-----+-----+
@@ -1148,10 +1150,10 @@ END
is the SIZE of the following fields NODEID and ADDRESSES in bytes.
In network byte order.
</dd>
- <dt>NODEID</dt>
+ <dt>NODEKEY</dt>
<dd>
- is the Node ID of the peer which has generated this HELLO.
- The length content of the NODEID is determined by the TYPE field.
+ is the NodeKey of the node which has generated this HELLO.
+ The length content of this field is determined by the TYPE.
Usually, this is a cryptographic public key which allows the
Underlay to uniquely identify and authenticate the node.
</dd>
@@ -1168,7 +1170,7 @@ END
HELLO of a node.
</t>
<t>
- For the string representation of the peer public key,
+ For the string representation of the node public key,
the base-32 encoding "StringEncode" is used.
However, instead of following <xref target="RFC4648"/> the
character map is based on the optical character recognition friendly
@@ -1179,7 +1181,7 @@ END
<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>NODEID</tt>.
+ with the node identified by <tt>NODEKEY</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
@@ -1200,23 +1202,23 @@ tor+onionv3://rasdflkjasdfliasduf.onion/
<section>
<name>Bootstrapping</name>
<t>
- It is assumed that the peer is already connected to at least
- one other peer.
- First, those initial peers are sorted into their respective buckets.
+ It is assumed that the node is already connected to at least
+ one other node.
+ First, those initial nodes are sorted into their respective buckets.
</t>
<t>
- In order to find the closest peers in the network to itself, an
+ In order to find the closest nodes in the network to itself, an
implementation MUST now periodically send HELLO GET queries for its own
- peer ID.
- Both the "record route" and "find peer" message options are set in the
- GET queries in order to learn peers and network topology from the
+ node ID.
+ Both the "record route" and "find node" message options are set in the
+ GET queries in order to learn nodes and network topology from the
message route and in order to receive approximate replies to the
- query key (the peer ID).
+ query key (the node ID).
</t>
- <t>FIXME: Periodically -> more specific? No. Frequency may be adapted
depending on network conditions, known peers, busy/idle etc.</t>
+ <t>FIXME: Periodically -> more specific? No. Frequency may be adapted
depending on network conditions, known nodes, busy/idle etc.</t>
<t>
Any implementation encountering a HELLO GET request initially
- sends its own peer ID if it.
+ sends its own node ID if it.
</t>
</section>
<section anchor="security" numbered="true" toc="default">
@@ -1254,7 +1256,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 peer
+a HELLO for a node
11 GNS N/A GNS Block for storing record data
]]>
</artwork>
--
To stop receiving notification emails like this one, please contact
gnunet@gnunet.org.
- [lsd0004] branch master updated: peer vs node,
gnunet <=