How do I implement redundancy in RTI Connext?

Note: Relevant RTI Connext versions: RTI Connext 4.x and above.

There are a few QoS that relate to redundancy.

In order to support redundancy, you will want to use the Ownership QoS to specify a strength for each writer and specify  DDS_EXCLUSIVE_OWNERSHIP_QOS on both writers and readers. There is some discussion regarding possible use cases in the HTML documentation under the Ownership QoS.

Here are three common scenarios for redundancy: 

1. You can set up a primary writer and a lower-strength backup writer that both constantly publish. Ownership is resolved by the reader, with the ownership switching when the primary loses Liveliness or misses a Deadline. The switch-over time of this scheme is as precise as the liveliness lease duration/deadline plus the time it would take for RTI Connext to schedule an event callback (which in turn depends on the resolution of the OS-timed semaphore take facility). On VxWorks, for example, it is limited by the tick resolution.
2. You can set up a primary writer and a higher-strength backup writer which monitors the primary to determine when it (the backup writer) should start publishing. (You can still use the Liveliness or Deadline QoS to determine when the backup should take over). In this case, you must also determine whether you will restart the primary and return the backup to a dormant state, or whether the backup should become the new primary, in which case you will need to dynamically modify the ownership strength of the publications.
3. You can have the primary and backup be completely identical, except that the backup does not publish when the primary is considered alive by means of another heartbeat mechanism other than maintenance of ownership (such as through a user-defined heartbeat topic). 

For more details about implementing redundant systems, please ask our Services group about the RTI Connext Architecture Study Package. They can help build a customized system according to your needs.