doc: more stuff regarding protocol and domo_node
This commit is contained in:
parent
3365ca09a5
commit
5b16ffb7b7
5 changed files with 65 additions and 18 deletions
2
.gitignore
vendored
2
.gitignore
vendored
|
@ -1,2 +1,4 @@
|
|||
**/target/
|
||||
**/*.log
|
||||
# random testing
|
||||
domo_proto/src/main.rs
|
6
doc/domo_node/config.md
Normal file
6
doc/domo_node/config.md
Normal file
|
@ -0,0 +1,6 @@
|
|||
You can set up the node in very cool ways.
|
||||
|
||||
# `node.id` (optional)
|
||||
This will set the node's id.
|
||||
Your app may not start if the id is already taken.
|
||||
> tip: `0xFF------` is a free subnet in `domo_node`.
|
3
doc/domo_node/devnotes.md
Normal file
3
doc/domo_node/devnotes.md
Normal file
|
@ -0,0 +1,3 @@
|
|||
# Todo
|
||||
|
||||
- [ ] `0xFF------` subnet should be free to use without interference.
|
45
doc/domo_node/node_types.md
Normal file
45
doc/domo_node/node_types.md
Normal file
|
@ -0,0 +1,45 @@
|
|||
The `domo_node` implementation is quite limited.
|
||||
It's not made to be used standalone but rather in combination with other tools and use drivers.
|
||||
|
||||
# The Master node (`master`)
|
||||
Of these, there can only be one.
|
||||
The job of a master node is rather complex.
|
||||
|
||||
## Forwarding packets
|
||||
The most straight forward job of the node.
|
||||
It works by essentially having a hashmap with a reference to a socket.
|
||||
When a packet comes in the node gets forwarded to the right socket.
|
||||
|
||||
## Handling network state
|
||||
The master node ensures there are no duplicate identifiers and therefore nodes.
|
||||
Also, it will make sure no invalid updates can be sent.
|
||||
Most packets go through the master node before getting to the source.
|
||||
Most because the subnet node can have private nodes and handle those themselves.
|
||||
|
||||
# The Relay node (`relay`)
|
||||
The relay node is simple.
|
||||
In config you define where to forward the packets to, and they get delivered to there.
|
||||
|
||||
# The Subnet node (`subnet`)
|
||||
This is maybe another advanced node.
|
||||
It's a slave node that also acts as a master node.
|
||||
You can define private nodes in config, and they will be managed by the subnet node.
|
||||
For big domo networks this can be very useful to ensure privacy and keep control.
|
||||
|
||||
## Subnet properties
|
||||
The `domo_node` implementation ensures a couple properties.
|
||||
|
||||
### Lights (`all_lights` = `Switch`)
|
||||
With this property you can turn off all the lights in the subnet.
|
||||
This property will be absent is there are no lights present in the subnet.
|
||||
|
||||
> TODO: this feature requires distinction between switches and lights.
|
||||
> Either with extra identification information in `0x01`
|
||||
|
||||
### Enabled (`enabled` = `Switch`)
|
||||
Enable or disable the subnet.
|
||||
Functionality like: Master emulation, forwarding, private nodes will be paused.
|
||||
|
||||
### Forward (`forward` = `Swtich`)
|
||||
This will disable the forwarding of the subnet's node.
|
||||
Essentially make the subnet all private.
|
25
doc/proto.md
25
doc/proto.md
|
@ -99,25 +99,14 @@ there is no command data.
|
|||
|
||||
This command will register a node.
|
||||
|
||||
You can try to register as a node with a specific device_id but this might result in an error `0x03`.
|
||||
Leave `0` to get a random id.
|
||||
|
||||
#### Command data
|
||||
|
||||
| offset | size | name | description | example |
|
||||
|--------|---------|-------------|------------------------------------------------|--------------|
|
||||
| `0x14` | 4 bytes | `device_id` | the device identifier. (reserved for response) | `0x00000000` |
|
||||
|
||||
#### Example request
|
||||
|
||||
> source should be `0xFFFFFFFF` or MASTER's device id
|
||||
|
||||
```
|
||||
0x00000000
|
||||
```
|
||||
|
||||
#### Example response
|
||||
|
||||
```
|
||||
0x0A001001
|
||||
```
|
||||
| offset | size | name | description | reserved | example |
|
||||
|--------|---------|-------------|------------------------------------------------------------|----------|--------------|
|
||||
| `0x14` | 4 bytes | `device_id` | the device identifier. leave `0x00000000` to get random id | no | `0x00000000` |
|
||||
|
||||
### `0x02` - Remove node
|
||||
|
||||
|
@ -165,9 +154,11 @@ Send a packet to state an error occurred.
|
|||
| `0x00` | `net_duplicate_packet` | `reply_to` packet is invalid because another packet was sent recently with same `packet_id`. | resend with different `packet_id` |
|
||||
| `0x01` | `net_broken_packet` | recent packet was broken. | resend packet |
|
||||
| `0x02` | `net_invalid_packet` | the packet sent is not valid | send packet with proper values |
|
||||
| `0x03` | `net_addr_in_use` | the addr requested is in use already | register with another id or `0` |
|
||||
| `0x1*` | `errc_*` | **Client errors** | |
|
||||
| `0x10` | `errc_not_registered` | client is not registered | register client |
|
||||
| `0x2*` | `errs_*` | **Server errors** | |
|
||||
| `0x20` | `errs_not_delivered` | server could not deliver packet. | depends on situation |
|
||||
|
||||
## `0x1*` - Properties control
|
||||
|
||||
|
|
Loading…
Reference in a new issue