Recognizing Communication Patterns to Optimize Your DDS Application

When designing Connext applications, one important task is identify communication patterns and ensure the appropriate pattern is used for each topic.  There are typically three common data communication patterns, each optimized for different system behaviors and reliability requirements.

Each pattern is best supported by specific combinations of Quality of Service (QoS) policies to ensure predictable performance, reliability, scalability, and resource control in Connext applications.

This document summarizes:

• The most common DDS data patterns

• When to use each pattern

• Recommended QoS configurations

• Built-in QoS profile references

Periodic Data

Description

Data is published at a high frequency in a continuous stream. Examples include sensor readings, telemetry, and video frames.

When to Use

• Data is time-series and continuously updated

• Update rates are high

• Only the most recent value matters

• Occasional sample loss is acceptable

• Low latency is more important than guaranteed delivery

Typical Examples

• Telemetry streams

• Sensor measurements

• Monitoring feeds

• Video streams

Recommended QoS

This configuration minimizes latency and bandwidth usage when occasional loss is acceptable.

Built-in Profile

BuiltinQosLib::Pattern.PeriodicData

Special Case: Video with Key Frame / Delta Frame Encoding

When video uses key frame (I-frame) / delta frame (P/B-frame) encoding:

• Delta frames depend on prior frames

• Losing a key frame can invalidate many subsequent frames

• Frame dependency chains increase the impact of packet loss

In This Case, Consider:

Why RELIABLE May Be Better for Encoded Video

• Ensures key frames are delivered

• Reduces visible corruption caused by missing dependent frames

• Maintains decoder synchronization

State Data

Description

Represents the current state of an entity. Data is published only when the state changes.

When to Use

• The latest value must always be available

• Updates occur only when state changes

• Late joiners must receive the current state

• State replaces previous state

Typical Examples

• Device status

• Configuration settings

• Operating mode

• Health state

Recommended QoS

Built-in Profile

BuiltinQosLib::Pattern.Status

Command / Event Data

Description

Represents discrete commands or events that trigger actions. These are typically sporadic but critical.

Each event represents a meaningful occurrence and must be delivered reliably to all matching subscribers.

When to Use

• Each message must be delivered

• Events must not be lost

• Ordering matters

• Messages trigger actions

• Late joiners should NOT receive previously issued commands

Typical Examples

• Control commands

• Alarm notifications

• Trigger events

• Actuation requests

Recommended QoS

Why KEEP_ALL?

Using KEEP_ALL ensures:

• Every event is retained until successfully delivered

• No commands are overwritten by newer ones

• Subscribers can process every event in order

Events are not replaceable like state data; losing one may cause system inconsistency or incorrect behavior.

Using Lifespan to Age Out Old Data

The Lifespan QoS can be used to:

• Automatically discard stale commands

• Prevent unbounded memory growth

• Ensure time-sensitive events expire naturally

This is especially useful for:

• Time-bound triggers

• Event-driven workflows

Built-in Profile

BuiltinQosLib::Pattern.Event

Quick Pattern Selection Guide

Design Best Practices

• Use KEEP_LAST(1) for BEST_EFFORT or when when only the latest sample is significant.

• Use KEEP_LAST(n) when a limited number of samples are required for reliability caching.

• Use KEEP_ALL when every sample is significant.

• Use TRANSIENT_LOCAL only when late joiners must receive the latest state.

• Use VOLATILE for command data to avoid replaying old actions.

• Use Lifespan to bound resource usage in event-driven systems.

• Consider RELIABLE for video streams that use inter-frame compression.

• Tune ResourceLimits appropriately when using KEEP_ALL.

Conclusion

Correctly selecting DDS data patterns and aligning them with the appropriate QoS policies ensures:

• Predictable communication behavior

• Efficient bandwidth usage

• Proper handling of late joiners

• Controlled memory usage

• High system reliability

By mapping your use case to one of these three standard patterns and adjusting QoS policies accordingly, you can build robust and maintainable DDS-based distributed systems.  Remember that these recommendations are general best practices and further QoS configuration may be required to meet your unique requirements.