domo/doc/specification.md

47 lines
1.6 KiB
Markdown
Raw Normal View History

2023-11-30 21:52:49 +01:00
# Protocol Design
In this document I will define how this document is designed and how it should be implemented.
# Prelude
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL",
"NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
"node" or "nodes" are referring to a device that implements the Domo protocol.
## Transactions
All interactions between 2 nodes is called a transaction; a request and response.
The initial packet sent in the transaction is called the "origin packet".
A initial packet MUST NOT have a `reply_to`.
A transaction consists of 2 nodes;
- "Origin node"; the node who sent the origin packet.
- "Destination node"; the node who is marked as the destination by the origin packet.
# Behaviour
This chapter describes the behaviour of a node.
## Statuses
When an error occurs on the destination node in result of a request, the response to the origin node MUST be a `0x0E` (error command).
This MAY contain error data.
To mark a success, you MUST send back the request packet altered with the data specified in the protocol.
## Reserved addresses
### Broadcast (`0xFFFFFFFF`)
Nodes MUST listen to this address.
Owner nodes MUST forward this address to their owners if applicable.
# Packet inspection
## Error checking
If the CRC32 doesn't match up the destination node MUST send a `0x0E` (error) packet to the origin node.
The error code `0x01`/`net_broken_packet` MUST be used. The metadata MAY contain some textual info on what went wrong.
The master MUST not track the broken packet's `packet_id`, so the slave can send it again.