From 34d4fc56a3a058ce2e30b71d262f5724d99bd163 Mon Sep 17 00:00:00 2001 From: Christian Grothoff Date: Sun, 20 Aug 2023 15:21:05 +0200 Subject: take pass at terminology, suggest changes to disambiguate 'address' --- draft-schanzen-r5n.xml | 95 +++++++++++++++++++++++++++----------------------- 1 file changed, 51 insertions(+), 44 deletions(-) (limited to 'draft-schanzen-r5n.xml') diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml index a46db61..1601264 100644 --- a/draft-schanzen-r5n.xml +++ b/draft-schanzen-r5n.xml @@ -194,12 +194,12 @@ is a UTF-8 URI which can be - used to contact a peer. + used to contact a Peer. An example of an addressing scheme used in this document is "r5n+ip+tcp", which refers to a standard TCP/IP socket connection. The "hier"-part of the URI must provide a suitable address for the given addressing scheme. - The following are non-normative examples of address strings: + The following are non-normative examples of Address strings:
Applications
- Applications are components which directly use the DHT overlay - interfaces. Possible applications include the GNU Name System + Applications are higher-layer components which directly use the DHT overlay + interfaces. Possible Applications include the GNU Name System and the GNUnet Confidential Ad-hoc Decentralized End-to-End Transport (CADET) .
Application API
- The application API exposes the core operations of the DHT overlay - to applications. - This includes storing blocks in the DHT and retrieving blocks from the DHT. + The Application API exposes the core operations of the DHT overlay + to Applications. + This includes storing Blocks in the DHT and retrieving + Blocks from the DHT.
Block
Variable-size unit of payload stored in the DHT - under a Key. + under a Key. In the context of "key-value stores" this - refers to "value" stored under a key. + refers to "value" stored under a Key.
Block Storage
- The Block Storage component is used to persist and manage - Block data by peers. + The Block Storage component is used to persist and manage + Blocks stored by Peers. It includes logic for enforcing storage quotas, caching strategies and - data validation. + Block validation.
Block-Type
- A unique 32-bit value identifying the data format of a Block. - Block-Types are either private or registered in the GANA block type registry (see + A unique 32-bit value identifying the data format of a Block. + Block-Types are either private or registered in the GANA block type registry (see ).
Bootstrapping
- Bootstrapping is the initial process of establishing a connection to the peer-to-peer + Bootstrapping is the initial process of establishing a connection + to the peer-to-peer network. - This initially requires an initial, non-empty set of reachable peers and corresponding - addresses supported by the implementation to connect to. + This initially requires an initial, non-empty set of reachable Peers and corresponding + Addresses supported by the implementation to connect to.
Initiator
- The peer that initially creates and sends a DHT protocol message (, + The Peer that initially creates and sends a DHT protocol message (, , , ).
HELLO block
- A HELLO block is a block with a dedicated block type and is specified in this document. - The HELLO block is used to store and retrieve Peer addresses. + A HELLO block is a Block with a Block-Type DHT_HELLO (13). + A HELLO block is used to store and retrieve Addresses of a Peer. In this document, HELLO blocks are used by the peer discovery mechanism.
HELLO URL
- HELLO URLs are HELLO blocks in a URL representation. - They can used for out-of-band exchanges of peer information and are used for - address update signalling messages to neighbours. Example HELLO URLs and their + HELLO URLs are HELLO blocks represented as URLs. + They can used for out-of-band exchanges of Peer Address + information and are used for + address update signalling messages to Neighbours. Example HELLO URLs and their format can be found in .
Key
512-bit identifier of a location in the DHT. Multiple Blocks can be - stored under the same key. Peer Addresses are valid keys. + stored under the same Key. A Peer Address is also a Key. In the context of "key-value stores" this - refers to "key" under which values (blocks) are stored. + refers to "key" under which values (Blocks) are stored.
Message Processing
- The Message Processing component processes requests from and - generates responses to applications and the underlay network. + The Message Processing component of the DHT implementation processes + requests from and generates responses to Applications + and the Underlay Interface.
Neighbor
- A neighbor is a peer which is directly able to communicate - with our peer via the Underlay Interface. + A neighbor is a Peer which is directly able to communicate + with our Peer via the Underlay Interface.
Peer
- A host that is participating in the overlay. Peers are + A host that is participating in the overlay by running an implementation + of the DHT protocol. Each participating host is responsible for holding some portion of the data that has been stored in the overlay, and they are responsible for routing - messages on behalf of other hosts as needed by the Routing - Algorithm. + messages on behalf of other Peers as needed by the Routing + Algorithm.
+
Peer Address
- The Peer Address is the identifier used on the Overlay - to address a peer. - It is a SHA-512 hash of the Peer ID. + The Peer Address is the identifier used on the overlay + to identify a Peer. It is a SHA-512 hash of the Peer ID.
+
Peer ID
- The Peer ID is the public key which is used to authenticate - a peer in the underlay. - The Peer ID is the public key of the corresponding + The Peer ID is the public key which is used to authenticate + a Peer in the underlay. + The Peer ID is the public key of the corresponding Ed25519 peer private key.
Routing
- The Routing component includes the routing table as well as - routing and peer selection logic. It facilitates the R5N routing + The Routing component includes the routing table as well as + routing and Peer selection logic. It facilitates the R5N routing algorithm with required data structures and algorithms.
Responsible Peer
- The peer N that is responsible for a specific key K, as + The Peer N that is responsible for a specific key K, as defined by the SelectClosestPeer(K, P) algorithm (see .
Underlay Interface
- The Underlay Interface is an abstraction layer on top of the - supported links of a peer. Peers may be linked by a variety of + The Underlay Interface is an abstraction layer on top of the + 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, I2P or Tor. + TCP, UDP and TLS or higher-layer protocols such as GNUnet, I2P or Tor. +
-- cgit v1.2.3