fairmq/commands: Implement a protocol version

[AndreyLebedev]

Is your feature request related to a problem? Please describe.
Imagine the following example. ODC is built on a node using FairMQ version X. Then ODC starts a topology on a cluster where a FairMQ version Y is used. If there are no changes in the protocol between version X and Y then everything works fine. But if there are incompatible changes then the system stops working correctly.

Describe the solution you'd like
Having a protocol version helps to identify a possible incompatibility between two instances communicating via FairMQ.SDK. One can also consider having a schema evolution of the protocol but I think it's overkill.

[dennisklein]

In your example the FairMQ SDK client communicates to the FairMQ DDS plugin via DDS custom commands. Two possible implementations come to mind:

• Introduce some kind of a handshake message as first message exchange between client and plugin. If we already have a message that is always sent first, we could re-use it by adding a version field (to save one round-trip).
• Add the protocol version as an extra field to all the messages.

[dennisklein]

https://github.com/FairRootGroup/FairMQ/blob/868fe02ee9a332b1c7641c1da9bfa0f8e04ac46d/fairmq/sdk/Topology.h#L286-L287 This looks like a suitable message exchange to add also a version check.

It is always sent to all devices at the very beginning of the lifetime of a sdk::Topology object:
https://github.com/FairRootGroup/FairMQ/blob/868fe02ee9a332b1c7641c1da9bfa0f8e04ac46d/fairmq/sdk/Topology.h#L256

[AndreyLebedev]

Having a handshake with a version number is a good solution. But I would implement a dedicated handshake message for this purpose. Probably you'll want to extend a handshake message in the future with more checks.

[dennisklein]

Having a handshake with a version number is a good solution. But I would implement a dedicated handshake message for this purpose. Probably you'll want to extend a handshake message in the future with more checks.

I agree, looking at the code I realized @rbx was very thourough and already made a cmd::Cmds container:

https://github.com/FairRootGroup/FairMQ/blob/868fe02ee9a332b1c7641c1da9bfa0f8e04ac46d/fairmq/sdk/commands/Commands.h#L353-L403

So, we can have a clean, separate handshake type of message and still send it on the same round-trip together with the cmd::SubscribeToStateChange message. 🎉 😺

[dennisklein]

Only tricky part is, how and when to return if there are (partial) mismatches. The ctor has two modes,

• if it blocks, one could throw on mismatches, but
• if it does not block (default), one would need a new method (e.g. Topology::CheckPeerProtocolCompat() -> bool) to retrieve the result ...

[AndreyLebedev]

Another option is to return an error / throw an exception from any public API method of Topology until the handshake is complete.