RDSelector
RDSelector
For selecting the leader application from the redundant application group an RDSelector block has to be used. The RDSelector contacts all applications in the redundant application group and constantly listens to their heartbeat messages on the prioritized TCP communication channel and then elects one of them as the leader.
The elected leader is given out as the zero-based LeaderIndex of the application in the redundant application group. That LeaderIndex will then be used as an input for the RDSynchronizer blocks and also for any other blocks (like port MUX or DEMUX selectors in non-redundant applications) that need to know the current leader application.
The election is based on heartbeat message quality and also on some other information like application startup time and how long the application has already been selected as a leader. The RDSelector has a dedicated worker thread that connects to all the redundant applications (i.e. that are listed in RDAppList) and their RDSelectors via the prioritized TCP communication channel and starts listening to their heartbeats via that. The leader election takes place in every processing cycle of the RDSelector, so the corresponding output signal LeaderIndex reflects the change in application connectivity immediately, making it possible to switch over to the next working leader seamlessly, during one processing cycle of the redundant control system.
Note: For the fastest failover, always check that the RDSelector process frequency (the fs property) is the same as the maximum process frequency of any of the components in the application.
Optional QoS Logic Override
The RDSelector LeaderIndex calculation can be customized by adding some additional quality-of-service (QoS) logic (like which of the applications has less noise or errors in connected hardware, etc) to the built-in election logic. This is possible by writing a script into the QoSOverrideScript property in the ChaiScript language.
ChaiScript is a strongly typed declarative language with syntax similar to C++. The script can refer to input signals of the RDSelector (including unlimited number custom-added signals) and do any kind of logical calculation based on them and then reassign the LeaderIndex output signal as needed. The QoSOverrideScript supports the same set of built-in operators and functions that are described in the Chai script documentation.
An additional RDAppStatus can be added to the RDSelector that reflects the status of the application having that name. These RDAppStatus properties can also be referred in the QoSOverrideScript.
Note: Note that as variable in ChaiScript can not contain spaces all CDP node names that contain spaces in the name must be referred with spaces removed from the name (like 'My Signal' should be referred as 'MySignal' in ChaiScript).
The following example QoSOverrideScript overrides the LeaderIndex built-in logic so that the RDSelector always prefers App2, wherever it is becoming alive:
if (bool(App2.HBAlive)) { LeaderIndex = App2.Index; }
RDSynchronizer Signals, Properties and Messages
Signals
| Name | Direction | Description |
|---|---|---|
| LeaderIndex | Ouptut | Zero-based index of currently elected leader application in RDAppList. This value can be altered by custom logic by the script written into the QoSOverrideScript property. |
Properties
| Name | Special flag | Description |
|---|---|---|
| RDAppList | Semicolon-separated list of application names of the redundant applications to select the leader from. Note: Note, that the order of the application names in this property is very important as LeaderIndex signal acts as a zero-based index of the application in this list. | |
| QoSOverrideScript | Optional QoS override script written in the ChaiScript language to alter the LeaderIndex signal after RDSelector internal leader election. | |
| HBCommPort | Heartbeat communication TCP port number. In redundant applications (i.e. in applications that are listed in the RDAppList), starts listening on and sending heartbeat messages to companion RDSelectors via this. Will be auto-increased to the first available port in the range specified by HBCommPortRangeSize. Defaults to the first port in TCP ephemeral port range, 49152. Not used when the RDSelector is added to a non-redundant application (i.e. in applications that are NOT listed in the RDAppList). | |
| HBCommPortRangeSize | Heartbeat communication TCP available port scan range size, starting from HBCommPort. Defaults to 16383 to scan the whole TCP ephemeral port range from 49152 to 65535. Not used when the RDSelector is added to a non-redundant application (i.e. in applications that are NOT listed in the RDAppList). | |
| HBRate | Number of heartbeat messages that are expected to be received from RDSelectors during one process cycle. Process cycle frequency itself is adjustable by the fs property of the RDSelector. | |
| HBMissTolerance | Number of heartbeat messages that are allowed to be missed from RDSelector before the application will be considered not alive anymore (and it can not be elected as a leader anymore). | |
| LeaderChangeCount | Read-only | Number of leader changes detected in LeaderIndex, caused by the changed redundant application connectivity or heartbeat message delays or some other leader election logic input information (including user-overridden QoS logic). |
Messages
| Name | Description |
|---|---|
| CM_RESET | Sending this message will reset LeaderChangeCount and also all existing RDAppStatus nodes HBMissedCount values to zero |
See also RDSynchronizer and RDAppStatus.
Get started with CDP Studio today
Let us help you take your great ideas and turn them into the products your customer will love.