About RT

This page describes Reliable Transport (RT), the enterprise messaging system that manages reliable message streaming across a cluster.

As of KX Sensors 3.2, two enterprise messaging system (EMS) options are available: RT is used for multi-node deployments, and TP+ is used for single-node deployments.

Reliable Transport (RT) is a micro-service that manages the reliable streaming of messages using the Raft consensus algorithm to establish a quorum in the event of a network failure.

Central to RT is the RT sequencer. It merges sensor data received across multiple publishers, potentially spanning different nodes, into a single ordered log file for the entire cluster, which is then transferred to the external log file on each node. This ensures that the data in the external logs on each node is identical.

The Raft consensus algorithm requires an odd number of nodes (three or five) in your cluster. You can achieve an odd number of nodes in one of two ways:

• Two or four sensor nodes, plus one RT-only node.
• Three or five sensor nodes.

How RT processes run

As of KX Sensors 3.3, all RT processes run directly on the host.

KX Sensors v3 releases before 3.3 ran the RT sequencer and replicators as Docker containers, which made Docker a prerequisite of KX Sensors and required a Docker Swarm overlay network for RT traffic between hosts. Neither is required now, and neither is installed by the KX Sensors installation scripts. If you're still on a v3 release before 3.3, see Docker containers and swarm network.

• The RT Orchestrator (RTO) service class on each node remains responsible for starting, stopping, and monitoring the RT processes of each stream. Don't start or stop RT processes directly.
• RT is now a service class in its own right. RTO starts one RT process per stream, named kxsRT_<node>-<stream> — for example, kxsRT_A-emsint — in the same way that TPO starts one kxsTP_* process per stream for TP+.
• Because RT processes are ordinary KX Sensors processes, inspect them with kxsctl status RT rather than with container tooling. They no longer appear in docker ps.
• Upgrading the version of RT still requires an extra procedure. See RT upgrades.

RT cluster architecture

On each node, a push replicator receives messages from external publishers and writes them to a replicated log for that publisher. The RT sequencer on each node merges the replicated logs from all publishers into a single ordered log, coordinating with the RT sequencers on the other nodes using Raft. A pull replicator then transfers each node's merged log to the RTS service class on the corresponding KXS node, which writes it to the external log that SDL reads from.

Next steps

• About TP+
• Key processes