The Tao of Data Distribution: Transcending RPC

The Case for Connext: Achieving Enlightenment through DDS

The Data Distribution Service (DDS^®) standard embodies real-time communication based on the principles of data centricity – an enlightened approach to streaming data in distributed systems that is both robust and scalable. I’d like to take the reader on a journey towards understanding and accepting a smarter way to orchestrate critical systems.

Every journey begins with a single step, and ours is to understand the chains that bind. For example, in the world of RPC, your code lives in a state of perpetual dependency. When you invoke a remote procedure, you are bound to your destination by invisible chains – chains forged by the RPC illusion.

The RPC Illusion

This is the seductive notion that distributed systems can really behave like local function calls. Because by clinging to this familiar pattern, RPC forges chains that bind users to brittleness, to tight coupling, to a world where every component must know and depend upon every other. Those chains are:

• Spatial Coupling: You must know where your service lives – its address, its endpoint, its identity. Change the location, and the chain breaks.
• Temporal Coupling: You must call at the exact moment the service is available. If the server isn't listening, your request falls into the void.
• Interface Coupling: You must speak the exact language your counterpart expects. The function signature is a contract written in stone, and both parties must perform their roles in perfect synchrony.
• Life Cycle Coupling: Your fate is tied to theirs. If they die mid-conversation, so does your request. You wait, anxiously, for a response that may never come

DDS: Casting Off the Chains

The next stage in our journey is to free ourselves of these chains through decoupling. The first peek through the window of enlightenment comes with the realization that in a DDS environment, data can exist independently of its producers and consumers.

• Space Decoupling: Publishers and Subscribers meet in an abstract data space, finding each other through shared interest in topics, not through direct addressing. A component can appear, disappear, or multiply – the data flow continues, undisturbed. And because DDS is fundamentally peer-to-peer, it requires no broker. Like water finding its way through stone, communication in a DDS architecture flows and reshapes itself unbidden according to the contours of its world.
• Time Decoupling: Publishers can send data at any time, whether or not anyone is actively listening. With Quality of Service (QoS) policies such as Durability, late-joining subscribers can receive historical data they missed. The conversation transcends the moment – it becomes a persistent stream of shared truth.
• Interface Decoupling: Components only need to agree on the shape of the data, not on who provides it or who consumes it. You can therefore add new publishers, new subscribers, new data transformations – all without touching existing code.
• Life Cycle Decoupling: Components come and go like waves on the ocean. A publisher crashes? Subscribers seamlessly receive data from another. A subscriber restarts? It rejoins the data flow without disrupting anyone else. Applications can join and leave the system dynamically without manual configuration or service registration, reducing operational complexity and enabling truly distributed deployments. The failure of any single component won't break the whole. Data outlives applications.

Loose coupling is what makes DDS attractive in environments where time is always of the essence and reliability is paramount.

Glimpsing the Data-Centric Horizon

You are now well along the path to awareness, but grasping a few more facets of DDS will complete your journey, particularly understanding how its principles manifest in practice through implementations such as RTI Connext:

Scalability and Multicast Efficiency: While the DDS standard is transport-agnostic, its data-centric design maps naturally onto efficient multicast protocols in real-world implementations. A single publication can reach thousands of subscribers without the linear scaling penalties associated with point-to-point RPC calls. This multicast capability becomes increasingly valuable as system complexity and participant count grow.

Real-Time Performance and Determinism: DDS enables predictable, low-latency communication with QoS guarantees that are essential for real-time systems. DDS offers configurable reliability, durability, and timing constraints that can be tuned per data stream, enabling systems to meet strict timing requirements in aerospace, automotive, and industrial automation domains.

Data-Centric Thinking: Rather than thinking in terms of remote procedure invocations, DDS applications embrace data-centric design. Instead of calling getTemperature(), applications subscribe to temperature data streams. This shift enables more efficient caching, reduces network traffic via intelligent filtering at the source, and naturally supports scenarios where multiple components need the same information. Once adopted, a data-centric system flows with change: types can evolve and instances can scale, allowing applications to grow and adapt as needs arise.

Observable State Pattern: The observable state pattern represents a fundamental shift from request-response state queries to continuous state observation. Rather than polling for current state ("What is the user's status?"), components subscribe to state change streams and automatically maintain local copies. QoS policies ensure these local copies converge over time, achieving eventual consistency once updates cease. State becomes a living, observable entity where late-joining subscribers receive current values immediately upon subscription while also receiving subsequent updates. This pattern eliminates polling overhead, enables timely propagation of state changes across distributed components, and enables reactive programming where components automatically respond to state changes. Multiple consumers can observe the same state simultaneously without additional overhead on the publisher, leveraging DDS's multicast efficiency.

Event-Driven Architecture: DDS naturally supports event-driven architectures where system behavior emerges from data flow rather than explicit control flow. This approach often leads to more resilient systems that gracefully handle partial failures and varying network conditions.

The Zen of QoS

With DDS, the enlightened developer achieves a state of transcendence by expertly configuring the QoS policies. The developer is then able to live by the following aphorisms:

"I publish temperature data. I don't know who needs it, or when they'll read it, but data goes wherever it is needed and whenever it is needed."

"I subscribe to position updates. I don't need to know who publishes them, how many sources exist, or where they are. In the end, all data arrives reliably, every time."

To the uninitiated, this sounds like laissez faire set-it-and-forget-it, but it is actually architectural wisdom. By embracing a wide array of QoS policies, you create systems that flex, adapt, and scale. You can deploy new sensors without reconfiguring subscribers. You can add redundant publishers for reliability. You can replace entire subsystems without recompiling the world.

Connext is an enterprise-grade communication fabric based on the DDS standard. It fundamentally simplifies individual components and codebases by decoupling data producers from consumers. The rich QoS features built into Connext allow developers to fine-tune the behavior of each data stream by declaring how data should be handled: reliability guarantees, delivery timing constraints, and resource allocation without writing custom logic. Moreover, this expanded set of QoS policies is one of the key advantages that sets Connext apart from other open-source and commercial DDS implementations..

Connext eliminates the brittle orchestration logic that plagues RPC systems, allowing applications to scale naturally from embedded devices to cloud deployments while maintaining predictable performance that RPC-style architectures struggle to achieve at scale.

The Cost of Enlightenment

RPC may seem comfortable because it mirrors how we think about function calls. It's familiar, synchronous, request-meets-response. Our path to enlightenment requires letting go of this comfort:

• By thinking in streams, not calls
• By embracing eventual consistency, not immediate certainty
• By designing for autonomy, not orchestration

But those who walk this path discover something profound: systems that are more resilient, more scalable, and paradoxically, more simple – because each component only knows what it needs to know, and nothing more.

We can now see through the Window of Enlightenment, but we shouldn’t lose sight of the fact that true enlightenment recognizes that not all problems demand decoupling. Sometimes you need request-response. Sometimes tight coupling is the right answer. But now you have a choice – and you understand the trade-offs.

The enlightened architect knows when to bind and when to release, when to couple and when to decouple. That wisdom, not dogma, is the true path.

About the author:

Andy Hall is a Senior Field Application Engineer at RTI, bringing over two decades of expertise in distributed systems, embedded systems and high-performance software architectures to various industries. Covering EMEA, Andy specializes in designing and implementing robust, scalable solutions that meet the demanding requirements of mission-critical environments.

Andy provides pre-sales technical consultation, system architecture guidance, and post-deployment support, helping companies leverage RTI's advanced communication technologies to enhance the operational efficiency and reliability of real-time systems.