Best practices for nodes configuration syntonization

Applications & Usage
1

In my system, different nodes share some identical configuration parameters that rarely change (approximately once per month) but could change while the system is running. It is not critical to restart a node during its reconfiguration. However, it is crucial that all nodes remain synchronized when the system is in operation mode.

I am exploring the best options to implement this behavior. Here are my options, along with some pros and cons from my perspective:

  • uavcan/register

    • Option 1: Populate identical configuration parameters in each node’s registry.
      • Pros:
        • Utilizes standard functionality.
      • Cons:
        • Requires special synchronization logic (and maybe tool), especially when adding new nodes to an already configured system in operation mode.
    • Option 2: Store identical configuration parameters in a central node registry from which other nodes read.
      • Pros:
        • Utilizes standard functionality.
        • Simplifies synchronization logic, but still requires some notifications to other nodes about configuration updates when the system is in operation mode.
      • Cons:
        • Overuse standard functionality.

  • Provide a dedicated service for reading identical configuration parameters

    • Pros:
      • Similar to the Option 2 of uavcan/register but does not overuse its functionality.

  • Periodically publish identical configuration parameters from a central node

    • Pros:
      • Straightforward and organic implementation.
    • Cons:
      • Almost all of the utilized bandwidth is senseless because it sends similar data.

  • Publish identical configuration parameters from a central node only when a new node appears or a configuration parameter changes

    • Pros:
      • Uses only the necessary amount of bandwidth.
      • Synchronization logic is straightforward.
    • Cons:
      • Still requires synchronization logic.

I may be missing some other options.

Currently, I am leaning towards the last option with implementation in a separate node. However, this approach (and actually all others) seems to deviate from the distributed system paradigm.

I am a bit confused by this task and would be very grateful for any valuable feedback or suggestions on this topic.

2

What entity initiates the changes? The nodes themselves, another node, or an external entity (perhaps a human or some automation)? The optimal approach may depend on this.

Based on the incomplete description your preferred approach makes sense.

Perhaps another option you could consider (I don’t know whether it is sensible in your case but you should be aware of it) is to publish the hash (CRC64 over names and values) of the configuration parameters periodically. Every subscriber would compare their local hash against the published value and re-read the parameters in case of divergence.

You could also publish all parameters continuously; as long as you do it at the OPTIONAL priority level there will be no interference with higher-priority activities on the network.

3

In my case, the changes come from an external entity, particularly a human.

Interesting idea, but it seems a bit complicated to implement because, in such a case, the node would need to execute additional requests to get configuration parameters after detecting a hash mismatch. Given my point that uavcan/register must be left for per-node configuration, I would also need to introduce new DSDLs for it.

Oh, thank you for that hint. I forgot about the Cyphal priority feature. The OPTIONAL priority perfectly suits my case.

So, for now, I am going with my preferred approach plus OPTIONAL priority for all messages published by this configuration publishing node.

@pavel.kirienko thank you for your advices.

1 Like