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.