On 10/1/2025 1:27 AM, Jan Friesse wrote:
you mostly answered all your questions yourself correctly :)
Heh, yah, I guess I should've gone source code spelunking before pestering the mailing list rather than after :).
why there is no multiple links supported (yet) is really it is not implemented - it's one of todo (https://github.com/corosync/corosync- qdevice/issues/23).
In the context of that feature request, "multiple links" would mean maintaining more than one connection simultaneously rather than having to reinitiate a connection when the current open one fails? So rather than having to take the time to connect, you could simply immediately communicate on a different link when communication on the currently active one failed.
Would you want to mimic the link mode as defined by the corosync protocol, and have passive/active/rr options available? Or do something simpler?
Then presumably there should be some keep alive traffic on links not in use to prevent any intermediate network equipment from timing out state.
Adding this feature would only require updating the qdevice-net code, not the qnetd code, as the latter already listens on all available interfaces? Unless something was needed on that side for keep alive traffic I suppose.
Configuration wise, would it accept multiple Host entries rather than just one, and each one would define a single IP address or a set of IP addresses mapped from a hostname that would be used for that "link"?
Thanks for the reply, I might take a look at implementing this... _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
