You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
56 lines
1.4 KiB
Plaintext
56 lines
1.4 KiB
Plaintext
3 years ago
|
time to plan
|
||
|
|
|
||
|
|
terms
|
||
|
|
|
||
|
|
RLC - reactor level coordinator (Beagleboard)
|
||
|
|
RH - Reactor Handler (goroutine)
|
||
|
|
SH - sensor handler (gourtine)
|
||
|
|
Reactor Side:
|
||
|
|
|
||
|
|
needs
|
||
|
|
- way to discover active sensors
|
||
|
|
- spin up goroutine for each sensor responsible for keeping status and logs
|
||
|
|
- way to read back and truncate logs for safe data delivery to servr
|
||
|
|
- routing requests from reactor level coordinator to relevant sensor
|
||
|
|
- internal memory sharing and channels for reactor level coordination
|
||
|
|
|
||
|
|
thoughts
|
||
|
|
- maybe the RLC can be responsible for packaging data for coordinator response
|
||
|
|
adv:
|
||
|
|
- clears up the network
|
||
|
|
- simplifies pinging
|
||
|
|
- keeps the data aributrary
|
||
|
|
cons:
|
||
|
|
- unknown data size
|
||
|
|
- how to coordinate data structure
|
||
|
|
|
||
|
|
Server Side:
|
||
|
|
|
||
|
|
needs
|
||
|
|
- way to look into a config file for active reactors
|
||
|
|
- should then spin up a goroutine for each reactor
|
||
|
|
- responsible for recovery and consistent communication
|
||
|
|
- individual database entries
|
||
|
|
- API?
|
||
|
|
- use gRPC for comms between server and BB
|
||
|
|
- each reactor handler needs mechanism for pinging, recovery, and database correctness
|
||
|
|
-
|
||
|
|
|
||
|
|
message PingRequest {
|
||
|
|
// do we even need anything in a ping request?
|
||
|
|
}
|
||
|
|
|
||
|
|
message PingResponse {
|
||
|
|
repeated Sensor sensor = 1;
|
||
|
|
}
|
||
|
|
|
||
|
|
message Sensor {
|
||
|
|
string type = 1;
|
||
|
|
bool status = 2;
|
||
|
|
byte data = 3;
|
||
|
|
}
|
||
|
|
|
||
|
|
sensors := [string]q
|
||
|
|
|
||
|
|
|