commit d7ab94c8d16f2024c4f85357a855252b4b393e10
parent 11ce6be242f95a61018d1dd224401accde6ca9ad
Author: Martin Schanzenbach <schanzen@gnunet.org>
Date: Wed, 22 Nov 2023 16:48:39 +0100
minor update
Diffstat:
2 files changed, 78 insertions(+), 76 deletions(-)
diff --git a/users/start.rst b/users/start.rst
@@ -1,5 +1,5 @@
-Starting and stopping
----------------------
+Getting started
+---------------
Prior to using any GNUnet-based application, one has to start a node:
diff --git a/users/subsystems.rst b/users/subsystems.rst
@@ -1,5 +1,5 @@
Subsystems
-==========
+**********
This section consists brief description of the subsystems that make up
GNUnet.
@@ -8,7 +8,7 @@ This image is giving an overview over system dependencies and interactions.
.. image:: /images/gnunet-arch-full.svg
CADET - Decentralized End-to-end Transport
-------------------------------------------
+==========================================
The Confidential Ad-hoc Decentralized End-to-end Transport (CADET) subsystem
in GNUnet is responsible for secure end-to-end
@@ -278,14 +278,15 @@ the original scheme and thus did not warrant space in the research
report.
.. todo:: Find missing link to file system paper.
+
.. index::
double: GNU Name System; subsystem
see: GNS; GNU Name System
.. _GNU-Name-System-_0028GNS_0029:
-GNS - the GNU Name System
-=========================
+GNS - the GNU Name system
+-------------------------
The GNU Name System (GNS) is a decentralized database that enables users
to securely resolve names to values. Names can be used to identify other
@@ -327,6 +328,77 @@ users, and the DHT to exchange data between users. A plugin API is used
to enable applications to define new GNS record types.
.. index::
+ single: GNS; name cache
+ double: subsystem; NAMECACHE
+
+.. _GNS-Namecache:
+
+NAMECACHE — DHT caching of GNS results
+======================================
+
+The NAMECACHE subsystem is responsible for caching (encrypted)
+resolution results of the GNU Name System (GNS). GNS makes zone
+information available to other users via the DHT. However, as accessing
+the DHT for every lookup is expensive (and as the DHT's local cache is
+lost whenever the peer is restarted), GNS uses the NAMECACHE as a more
+persistent cache for DHT lookups. Thus, instead of always looking up
+every name in the DHT, GNS first checks if the result is already
+available locally in the NAMECACHE. Only if there is no result in the
+NAMECACHE, GNS queries the DHT. The NAMECACHE stores data in the same
+(encrypted) format as the DHT. It thus makes no sense to iterate over
+all items in the NAMECACHE – the NAMECACHE does not have a way to
+provide the keys required to decrypt the entries.
+
+Blocks in the NAMECACHE share the same expiration mechanism as blocks in
+the DHT – the block expires wheneever any of the records in the
+(encrypted) block expires. The expiration time of the block is the only
+information stored in plaintext. The NAMECACHE service internally
+performs all of the required work to expire blocks, clients do not have
+to worry about this. Also, given that NAMECACHE stores only GNS blocks
+that local users requested, there is no configuration option to limit
+the size of the NAMECACHE. It is assumed to be always small enough (a
+few MB) to fit on the drive.
+
+The NAMECACHE supports the use of different database backends via a
+plugin API.
+
+.. index::
+ double: subsystem; NAMESTORE
+
+.. _NAMESTORE-Subsystem:
+
+NAMESTORE — Storage of local GNS zones
+======================================
+
+The NAMESTORE subsystem provides persistent storage for local GNS zone
+information. All local GNS zone information are managed by NAMESTORE. It
+provides both the functionality to administer local GNS information
+(e.g. delete and add records) as well as to retrieve GNS information
+(e.g to list name information in a client). NAMESTORE does only manage
+the persistent storage of zone information belonging to the user running
+the service: GNS information from other users obtained from the DHT are
+stored by the NAMECACHE subsystem.
+
+NAMESTORE uses a plugin-based database backend to store GNS information
+with good performance. Here sqlite and PostgreSQL are supported
+database backends. NAMESTORE clients interact with the IDENTITY
+subsystem to obtain cryptographic information about zones based on egos
+as described with the IDENTITY subsystem, but internally NAMESTORE
+refers to zones using the respective private key.
+
+NAMESTORE is queried and monitored by the ZONEMASTER service which periodically
+publishes public records of GNS zones. ZONEMASTER also
+collaborates with the NAMECACHE subsystem and stores zone information
+when local information are modified in the NAMECACHE cache to increase look-up
+performance for local information and to enable local access to private records
+in zones through GNS.
+
+NAMESTORE provides functionality to look-up and store records, to
+iterate over a specific or all zones and to monitor zones for changes.
+NAMESTORE functionality can be accessed using the NAMESTORE C API, the NAMESTORE
+REST API, or the NAMESTORE command line tool.
+
+.. index::
double: HOSTLIST; subsystem
.. _HOSTLIST-Subsystem:
@@ -751,76 +823,6 @@ Also MESSENGER provides multiple features with privacy in mind:
other members to draw conclusions from communication partners
-.. index::
- single: GNS; name cache
- double: subsystem; NAMECACHE
-
-.. _GNS-Namecache:
-
-NAMECACHE — DHT caching of GNS results
-======================================
-
-The NAMECACHE subsystem is responsible for caching (encrypted)
-resolution results of the GNU Name System (GNS). GNS makes zone
-information available to other users via the DHT. However, as accessing
-the DHT for every lookup is expensive (and as the DHT's local cache is
-lost whenever the peer is restarted), GNS uses the NAMECACHE as a more
-persistent cache for DHT lookups. Thus, instead of always looking up
-every name in the DHT, GNS first checks if the result is already
-available locally in the NAMECACHE. Only if there is no result in the
-NAMECACHE, GNS queries the DHT. The NAMECACHE stores data in the same
-(encrypted) format as the DHT. It thus makes no sense to iterate over
-all items in the NAMECACHE – the NAMECACHE does not have a way to
-provide the keys required to decrypt the entries.
-
-Blocks in the NAMECACHE share the same expiration mechanism as blocks in
-the DHT – the block expires wheneever any of the records in the
-(encrypted) block expires. The expiration time of the block is the only
-information stored in plaintext. The NAMECACHE service internally
-performs all of the required work to expire blocks, clients do not have
-to worry about this. Also, given that NAMECACHE stores only GNS blocks
-that local users requested, there is no configuration option to limit
-the size of the NAMECACHE. It is assumed to be always small enough (a
-few MB) to fit on the drive.
-
-The NAMECACHE supports the use of different database backends via a
-plugin API.
-
-.. index::
- double: subsystem; NAMESTORE
-
-.. _NAMESTORE-Subsystem:
-
-NAMESTORE — Storage of local GNS zones
-======================================
-
-The NAMESTORE subsystem provides persistent storage for local GNS zone
-information. All local GNS zone information are managed by NAMESTORE. It
-provides both the functionality to administer local GNS information
-(e.g. delete and add records) as well as to retrieve GNS information
-(e.g to list name information in a client). NAMESTORE does only manage
-the persistent storage of zone information belonging to the user running
-the service: GNS information from other users obtained from the DHT are
-stored by the NAMECACHE subsystem.
-
-NAMESTORE uses a plugin-based database backend to store GNS information
-with good performance. Here sqlite and PostgreSQL are supported
-database backends. NAMESTORE clients interact with the IDENTITY
-subsystem to obtain cryptographic information about zones based on egos
-as described with the IDENTITY subsystem, but internally NAMESTORE
-refers to zones using the respective private key.
-
-NAMESTORE is queried and monitored by the ZONEMASTER service which periodically
-publishes public records of GNS zones. ZONEMASTER also
-collaborates with the NAMECACHE subsystem and stores zone information
-when local information are modified in the NAMECACHE cache to increase look-up
-performance for local information and to enable local access to private records
-in zones through GNS.
-
-NAMESTORE provides functionality to look-up and store records, to
-iterate over a specific or all zones and to monitor zones for changes.
-NAMESTORE functionality can be accessed using the NAMESTORE C API, the NAMESTORE
-REST API, or the NAMESTORE command line tool.
.. index::
single: subsystem; Network size estimation
