# Best practices for nodes configuration syntonization

**URL:** <https://forum.opencyphal.org/t/best-practices-for-nodes-configuration-syntonization/2146>\
**Category:** Applications & Usage\
**Created:** [June 24, 2024, 9:07pm UTC](https://forum.opencyphal.org/t/best-practices-for-nodes-configuration-syntonization/2146 "2024-06-24T21:07:20Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![ych](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/ych/32/1510_2.png) [@ych](https://forum.opencyphal.org/u/ych)\
**Post date:** [June 24, 2024, 9:07pm UTC](https://forum.opencyphal.org/t/best-practices-for-nodes-configuration-syntonization/2146/1 "2024-06-24T21:07:20Z")

</div>

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`

- Provide a dedicated service for reading identical configuration parameters

- Periodically publish identical configuration parameters from a central node

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

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.

---

<div class="post-metadata">

**Author:** ![pavel.kirienko](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/pavel.kirienko/32/9_2.png) [@pavel.kirienko](https://forum.opencyphal.org/u/pavel.kirienko)\
**Post date:** [July 5, 2024, 12:03pm UTC](https://forum.opencyphal.org/t/best-practices-for-nodes-configuration-syntonization/2146/2 "2024-07-05T12:03:49Z")

</div>

> [@ych](#):
>
> different nodes share some identical configuration parameters that rarely change (approximately once per month) but could change while the system is running

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.

---

<div class="post-metadata">

**Author:** ![ych](https://forum.opencyphal.org/user_avatar/forum.opencyphal.org/ych/32/1510_2.png) [@ych](https://forum.opencyphal.org/u/ych)\
**Post date:** [July 7, 2024, 2:36pm UTC](https://forum.opencyphal.org/t/best-practices-for-nodes-configuration-syntonization/2146/3 "2024-07-07T14:36:48Z")

</div>

> [@pavel.kirienko](#):
>
> 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.

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

> [@pavel.kirienko](#):
>
> 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.

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.

> [@pavel.kirienko](#):
>
> 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.

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.