gnunet-handbook

The GNUnet Handbook
Log | Files | Refs

architecture.rst (3263B)

      1 
      2 .. _System-Architecture:
      3 
      4 *******************
      5 System Architecture
      6 *******************
      7 
      8 .. todo:: 
      9    FIXME: For those irritated by the textflow, we are missing images here,
     10    in the short term we should add them back, in the long term this should
     11    work without images or have images with alt-text.
     12 
     13 .. todo:: Adjust image sizes so that they are less obtrusive.
     14 
     15 GNUnet developers like LEGOs. The blocks are indestructible, can be
     16 stacked together to construct complex buildings and it is generally easy
     17 to swap one block for a different one that has the same shape. GNUnet's
     18 architecture is based on LEGOs:
     19 
     20 |service_lego_block|
     21 
     22 This chapter documents the GNUnet LEGO system, also known as GNUnet's
     23 system architecture.
     24 
     25 The most common GNUnet component is a service. Services offer an API (or
     26 several, depending on what you count as \"an API\") which is implemented
     27 as a library. The library communicates with the main process of the
     28 service using a service-specific network protocol. The main process of
     29 the service typically doesn't fully provide everything that is needed
     30 --- it has holes to be filled by APIs to other services.
     31 
     32 A special kind of component in GNUnet are user interfaces and daemons.
     33 Like services, they have holes to be filled by APIs of other services.
     34 Unlike services, daemons do not implement their own network protocol and
     35 they have no API:
     36 
     37 |daemon_lego_block|
     38 
     39 The GNUnet system provides a range of services, daemons and user
     40 interfaces, which are then combined into a layered GNUnet instance (also
     41 known as a peer).
     42 
     43 |service_stack|
     44 
     45 Note that while it is generally possible to swap one service for another
     46 compatible service, there is often only one implementation. However,
     47 during development we often have a \"new\" version of a service in
     48 parallel with an \"old\" version. While the \"new\" version is not
     49 working, developers working on other parts of the service can continue
     50 their development by simply using the \"old\" service. Alternative
     51 design ideas can also be easily investigated by swapping out individual
     52 components. This is typically achieved by simply changing the name of
     53 the \"BINARY\" in the respective configuration section.
     54 
     55 Key properties of GNUnet services are that they must be separate
     56 processes and that they must protect themselves by applying tight error
     57 checking against the network protocol they implement (thereby achieving
     58 a certain degree of robustness).
     59 
     60 On the other hand, the APIs are implemented to tolerate failures of the
     61 service, isolating their host process from errors by the service. If the
     62 service process crashes, other services and daemons around it should not
     63 also fail, but instead wait for the service process to be restarted by
     64 ARM.
     65 
     66 .. todo::
     67    
     68    Missing subsystems:
     69       * TOPOLOGY, FRAGMENTATION
     70       * VPN and support services (DNS, PT, EXIT)
     71       * DATASTORE (only used by FS?)
     72       * MULTICAST and social services (PSYC, PSYCSTORE, SOCIAL)
     73       * GNS support services/applications (GNSRECORD, ZONEMASTER)
     74       * Set-based applications (SCALARPRODUCT, SECRETSHARING, CONSENSUS, VOTING)
     75 
     76 .. |service_lego_block| image:: /images/service_lego_block.png
     77 .. |daemon_lego_block| image:: /images/daemon_lego_block.png
     78 .. |service_stack| image:: /images/service_stack.png