-
Notifications
You must be signed in to change notification settings - Fork 0
Architecture
The MSGp service is broadly structured into four components: user/value database handling, device database handling, the API, and a hub providing for communication between concurrent api connections.
The user/value database resides in the db package. db/interfaces.go contains the list of interfaces to the database: there are Users, which have Devices, which have Sensors, which have Values. Users and Sensors can belong to groups to share access to the measurments. Everything is stored in a PostgreSQl database.
All access to the user database is handled through the Tx object, which which provides transactions for viewing and modifying the database.
Since Users, Devices and Sensors form a hierarchy, removing an instance of any object automatically removes all instances of nested objects. Sensor readings and aggregated reading are also cleared.
For more details refer to User Database
The device database lives in the regdev package. Like the user database, the device database behave a lot like a BoltDB database. Every physical (or logical) devices that wants to talk to the MSGp service will require an entry in the device database, which stores management and health information of the devices.
In particular, network configurations are stored in the database to allow configuration of devices through a web interface. Health information is stored in the form of heartbeats, which the device may send at any time to retrieve configuration information and inform the service about its current status (including statistics like current memory usage, uptime and so on).
The device database also stores to which user a device has been connected as part of the device configuration information.
The API handles all communication between servers and clients. There are three different APIs, each handling a subset of operations:
- the regdev API (in
regdev/deviceserver.gohandles device configuration, heartbeat and lifecycle management - the websocket API (in
wsapi.go) handles everything websocket related (sending updates, retrieving values for display, ...) - the user API (in
cmd/msgpd/main.go) handles user-visible configuration of devices and sensors
The websocket API is subdivided into a User API and a Device API.
The user API is used mainly by the sensor graphing page of the web interface. Each instance of the graphing page opens a websocket connection linked to the logged in user. This connection is then used to request all currently known sensor metadata for display, to retreive and receive recorded sensor values, and to request that devices send realtime updates for sensors which support it.
The device API handles all device actions that involve sensors and sensor values. With the device API, sensors can be created and removed, sensor metadata can be changed and sensor values can be sent.
The hub (in hub/hub.go) is used to allow different connections pertaining to the same user to communicate with each other. To do so, every connection that is interested in communication may listen on the hub by subscribing to topics, or it may send messages with arbitrary message content to a specific topic.
The hub is used by the user and device API to broadcast updates of sensors values, sensor metadata and other information.