Developing lightweight computation at the DSG edge

Commit 369eb4e9 authored by Roger Pueyo Centelles's avatar Roger Pueyo Centelles
Browse files

Update Readme


Signed-off-by: default avatarRoger Pueyo Centelles <roger.pueyo@guifi.net>
parent 73e9cd34
......@@ -48,9 +48,7 @@ $ go run monitor-fetch.go
0 IPv4 addresses removed from AntidoteDB (0 success, 0 fail)
10634 devices added to AntidoteDB (10634 success, 0 fail) ...
```
etc.
Smaller subnetworks can be used instead, like the Guifi-UPC subnetwork, for testing purposes:
etc. Smaller subnetworks can be used instead, like the Guifi-UPC subnetwork, for testing purposes:
```
$ go run monitor-fetch.go -cnml_file upc.xml
19 nodes read from upc.xml
......@@ -73,3 +71,50 @@ go run monitor-ping.go <host>
Previously as of this note on Linux support: _this library attempts to send an "unprivileged" ping via UDP. On Linux, this must be enabled by setting_:
```sudo sysctl -w net.ipv4.ping_group_range="0 2147483647"```
## Data structures in AntidoteDB
### Devices/Monitors assignation
The primary data source for this application is the CNML file. The `monitor-fetch` application parses the specified CNML file and pushes its contents to AntidoteDB. There is a single `monitor-fetch` instance, and its writes/updates are __authoritative__.
In AntidoteDB, the data are structured as follows:
#### guifi (bucket)
The `guifi` bucket contains the list of devices to be monitored:
##### guifi (bucket) => devices (set)
The `devices` *set* in the `guifi` *bucket* is an `array` of `strings`, each `string` containing the `ID` of a Guifi.net device. For example:
```bash
$ curl localhost:3000/set/read/guifi/devices
["22110","26932","38720","40605","40962","41175","42331","42626","42627","42628",
"46654","46656","47103","48030","51580","57728","59001","60415","64962","64963",
"64965","64966","65291","65720","72843","73952","79715","81297","82096","82097",
"82098","82099","82103","82104","82105","82111","83865","85877","87503","90228",
"92032","92802","92803","92804","94210","94965","96225","96676","96684"]
```
#### device-i (bucket)
The `device-i` bucket, where `i` is the numeric `ID` of a device in the `guifi/devices` set, contains the information about a Guifi.net device:
##### device-i (bucket) => ipv4s (set)
The `ipv4s` *set* in the `device-i` *bucket* is an `array` of `strings`, each `string` containing an IPv4 address of the device. For example:
```bash
$ curl localhost:3000/set/read/device-26932/ipv4s
["10.139.37.226","172.25.40.188","172.25.40.189"]
```
##### device-i (bucket) => monitors (set)
The `monitors` *set* in the `device-i` *bucket* is an `array` of `strings`, each `string` containing the ID of a monitor the device is assigned to (i.e. the `ID` of a monitor that is in charge of monitoring the device). For example:
```bash
$ curl localhost:3000/set/read/device-26932/monitors
["a45632","21435","a47363"]
```
##### device-i (bucket) => graphserver (LWW<sup>1</sup> register)
The `graphserver` *LWW register* in the `device-i` *bucket* is a `string` containing the ID of a monitor the device is assigned to **in the Guifi.net** website (i.e., not automatically assigned by the monitoring application, but done manually on the Guifi.net website, and included in the CNML). For example:
```bash
$ curl localhost:3000/register/read/device-26932/graphserver
71808
```
---
<sup>1</sup> LWW: last writer wins
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment