The max hostname length is not a trivial number, i.e., 256 bytes. The non-stop broadcasting of a node's host name in a large cluster increases the overhead on both network and CPUs when the cluster is in a steady state. This impact can also grow with more extensions added in the future, It will be great if a generic mechanism could be devised such that the broadcasting of these extensions can be optional and only activated when a change is detected in the cluster (for instance, hostname updates or new node arrivals).
Originally posted by @PingXie in https://github.com/redis/redis/pull/9530#discussion_r795144548
Comment From: madolson
The only downside to this is that you have to track what state has been sent to each node, which I thought was a lot to implement for this. In the fullness of time we've discussed tracking all this through a separate consensus system, so we have stronger guarantees about what is the "authoritative" state of the cluster.
Comment From: PingXie
Apologies if this topic was already discussed extensively in the past and I am repeating it here (happy to review the past discussions if there are links to share).
I think whether or not we need a (new) consensus system depends on the extension itself. In the case of "hostname", I would think all is needed is "eventual consistency", i.e., all other nodes in the cluster eventually learn about the new "hostname". This information doesn't seem to participate in any cluster state management. In this sense, "hostname" is different than the slots info broadcast in the gossip message.
I was wondering if a simple versioning scheme would work for "hostname" (or other extensions of the same nature). Basically, every "hostname" is associated with a node-level version and it gets bumped when a new "hostname" is set. Then in a static cluster, all gets exchanged (between the two nodes) are two version numbers (my "hostname" version and version of my copy of your "hostname"). These two numbers would be sufficient for any two nodes to know whether the other party has the latest "hostname". The version number would need to be persisted together with the "hostname" and some more flags might be needed to request the actual "hostname" after a new version is discovered. Admittedly, this is not a straightforward scheme but I think we could avoid a separate consensus system and build it on top of the existing gossip message.