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.
50 lines
2.4 KiB
Markdown
50 lines
2.4 KiB
Markdown
# Jan 23
|
|
|
|
### Connecting Clients to reactors
|
|
|
|
**Client -> Server -> Reactor**
|
|
|
|
I can take advantage of the private network created via wireguard to allow the server to connected back to individual reactors and then intiate gRPC calls.
|
|
|
|
**Pros**
|
|
- This *VASTLY* simplifies the implementation as I can now connect back to the reactors themselves
|
|
- from there, I can implement various functions I will need server side
|
|
- i.e. GetName() SetName() etc.
|
|
|
|
**Cons**
|
|
- I will eventually need to build the wiregaurd implementation
|
|
- although because its all local network for now, I can plug and play down the road
|
|
|
|
### TODO
|
|
- refactor packages to provide a cleaner interface via simple commands as opposed to the convoluted passing structure that was present with the old I2C library
|
|
- start working on the interface between the websocket and the reactor
|
|
- react side this is the actual content that will be rendered by the client
|
|
- server side this will be a connection to a reactor with the gRPC calls
|
|
- moving monitoring functionality to the reactor
|
|
- refactoring to use streaming functionality to avoid needing to re initiate request
|
|
- have server connect each reactor manager to the rlc
|
|
- have the reactor manager ping for server info
|
|
- handle disconnects via exit
|
|
- sets up cleaner device handling via multiplexing
|
|
|
|
# Jan 24
|
|
|
|
### Proto changes
|
|
|
|
It's time to refactor the current protobuf stuff to make more sense from the servers perspective. In this sense, I am going to have the reactor provide connection details to the server on connect, and then the server can connect/disconnect at will.
|
|
|
|
### Outline
|
|
- Update the server to connect to the reactor itself for the information
|
|
- Decide what information is important enough to send to the server consistently, vs what only is needed upon "further inspection"
|
|
- need reactor information on connect
|
|
- need basic device information such as address and status
|
|
- when selected
|
|
- need specific device breakouts with advanced functions per device
|
|
- this can be multiplexed over the same gRPC connection and can be fulfilled by the device coordinator
|
|
- dc will catch all incoming requests and forward to the correct DM based on address
|
|
|
|
### TODO
|
|
- reverse monitoring stuff
|
|
- make it so reactor manager has a timeout/ recognizes disconnects gracefully
|
|
- convert monitoring to a stream as opposed to consistent calls
|