commit 7adc54c64408944d12d83d0361cbdde56fcc9df3
parent af7b87a32c59d005a71c411b0f3eb86104e0f8ae
Author: Christian Grothoff <grothoff@gnunet.org>
Date: Thu, 10 Mar 2022 07:10:53 +0100
-misc terminology clarifications
Diffstat:
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/draft-schanzen-r5n.xml b/draft-schanzen-r5n.xml
@@ -180,47 +180,55 @@
a peer in the underlay.
The <tt>Peer Address</tt> is derived from the <tt>Peer ID</tt>.
</dd>
+ <dt>Key</dt>
+ <dd>
+ Fixed-sized identifier of a location in the DHT. Multiple <tt>Block</tt>s can be
+ stored under the same key. <tt>Peer Addresses</tt> must also always be valid keys.
+ </dd>
<dt>Neighbour:</dt>
<dd>
- A neighbour is a peer which is directly connected to our peer.
+ A neighbour is a peer which is directly able to communicate
+ with our peer via the <tt>Underlay Interface</tt>.
</dd>
<dt>Block:</dt>
<dd>
- An object or group of objects stored in the DHT.
+ Variable-size unit of payload stored in the DHT
+ under a <tt>Key</tt>. Commonly also called a "value" when talking
+ about a DHT as a "key-value store".
</dd>
<dt>Block-Type:</dt>
<dd>
- A unique 32-bit value identifying a block type.
+ A unique 32-bit value identifying the data format of a <tt>Block</tt>.
Block-Types are either private or allocated by GANA (see <xref target="gana"/>).
</dd>
<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
+ The <tt>Block Storage</tt> component is used to persist and manage <tt>Block</tt> data
+ by peers. It includes logic for enforcing storage quotas, caching strategies 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 peer <tt>N</tt> that is responsible for a specific key <tt>K</tt>, as defined by
the <tt>SelectClosestPeer(K, P)</tt> algorithm (see <xref target="routing"/>.
</dd>
<dt>Applications</dt>
<dd>
Applications are components which directly use the DHT overlay
interfaces. Possible applications include the GNU Name System
- <xref target="I-D.draft-schanzen-gns"/> or the CADET transport system
+ <xref target="I-D.draft-schanzen-gns"/> and the CADET transport system
<xref target="cadet"/>.
</dd>
<dt>Application API</dt>
<dd>
The application API exposes the core operations of the DHT overlay
to applications.
- This includes querying and retrieving data from the DHT.
+ This includes storing blocks in the DHT and retrieving blocks from the DHT.
</dd>
<dt>Message Processing</dt>
<dd>
- The Message Processing component processes requests from and responses
- to applications as well as messages from the underlay network.
+ The Message Processing component processes requests from and
+ generates responses to applications and the underlay network.
</dd>
<dt>Routing</dt>
<dd>
@@ -230,10 +238,10 @@
</dd>
<dt>Underlay Interface</dt>
<dd>
- The DHT Underlay Interface is an abstraction layer on top of the
+ 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, L2P or Tor.
+ TCP, UDP and TLS or advanced protocols such as GNUnet, I2P or Tor.
</dd>
</dl>
</section>
