gopkg.in/dedis/onet.v2@v2.0.0-20181115163211-c8f3724038a7/ARCHITECTURE.md (about)

     1  Navigation: [DEDIS](https://github.com/dedis/doc/tree/master/README.md) ::
     2  [Onet](README.md) ::
     3  Architecture
     4  
     5  # Architecture
     6  
     7  In ONet you define *Services* that use *Protocols* which can send and receive
     8  messages. Each *Protocol* is instantiated when needed as a *ProtocolInstance*.
     9  As multiple protocols can be run at the same time, there can be more than one
    10  *ProtocolInstance* of the same Protocol. Onet makes sure all messages get
    11  routed to the appropriate *ProtocolInstance*.
    12  
    13  Outside applications can communicate with ONet over the service-API which is
    14  implemented using protobuf over websockets, for JavaScript compatibility.
    15  
    16  This page is to describe the high level view of the cothority framework. We'll
    17  start first with a picture (because a picture is worth a thousand words :) and
    18  then dive into each main components of the library.
    19  
    20  ![architecture overview](architecture.png)
    21  
    22  As you can see there's a bunch of different entities involved. Let's get down
    23  the rabbit hole to explain the most important ones...
    24  
    25  
    26  ## Network stack
    27  
    28  The network stack is comprised of the Router which handles all incoming and
    29  outgoing messages from/to the network. A Router can use different underlying
    30  type of connections: TCP which uses regular TCP connections, Local which uses
    31  channels and is mainly for testing purposes, and TLS which is still in progress.
    32  More should be put into the network stack section.
    33  
    34  ## Conode
    35  
    36  It is  the main entity of a Cothority server. It holds the Router, the Overlay
    37  and the different Services. Generally, for developping an application using the
    38  framework, you would create your Router first, then the Conode and call
    39  `conode.Start()`.
    40  
    41  ## Roster
    42  
    43  It is simply a list of Conode denoted by their public key and address. A Roster
    44  is identified by its ID which is unique for each list.
    45  
    46  ## Tree
    47  
    48  It is a regular tree comprised of TreeNodes each of them denoted by their public
    49  key and address. It is constructed out of a Roster.
    50  
    51  ## Overlay
    52  
    53  It provides an abstraction to communicate over different Trees that the
    54  Protocols and Services need. It handles multiple tasks:
    55  
    56  * the propagations of the Roster and the Trees between different Conodes.
    57  * the creation of the Protocols
    58  * the dispatching of incoming and outgoing messages to the right Protocol.
    59  
    60  ## TreeNodeInstance
    61  
    62  It is created by the Overlay, one for each Protocol, being the central point of
    63  communication for a Protocol. It offers the latter some common tree methods such
    64  as `SendParent`,`SendChild`, `IsRoot` etc. More importantly, it transforms and
    65  embeds the message given by the Protocol into its own struct and dispatch it to
    66  the Overlay for the sending part; vice versa for the reception part.
    67  
    68  ## Protocol
    69  
    70  It is an interface where users of the library must implement the logic of the
    71  protocol they want to code. It is supposed to be a short term entity that is
    72  self sufficient,i.e. it does not need external access to any other resources of
    73  the Cothority framework. A protocol can be launched from: SDA itself, or by a
    74  Service. Look at the `protocols` folder in the repo to get an idea.
    75  
    76  ## Service
    77  
    78  It is a long term entity that is created when a Conode is created. It serves
    79  different purposes:
    80  
    81  * serving external client requests,
    82  * create/attach protocols with the Overlay, and launch them,
    83  * communicate information to other Services on other Conodes.
    84  
    85  ## ServiceManager
    86  
    87  It is the main interface between the Conode and the Service. It transforms  and
    88  embed the message created by the Service into its own format and pass it to the
    89  Conode for the sending part; vice versa for the reception part.