Developer resources · Why DDS?
Connect your systems.
Put data at the centre.
Data Distribution Service (DDS) is an open standard for sharing typed data between distributed applications. Define what your system needs to exchange, and how it needs to arrive.
Shared, typed interfaces.
Control delivery behaviour.
Interoperable by design.
Build your application. Not another communication framework.
Use established discovery, delivery and data-management mechanisms instead of rebuilding them for every project.
What changes with DDS
Add capabilities. Not more connections.
Publishers and subscribers meet through named, typed topics. Discovery matches compatible endpoints; their QoS policies define how they exchange data.
One producer. Independent consumers.
A sensor publishes a measurement once through its DDS writer. Processing and monitoring applications subscribe to the information they need.
New subscriber. Same data interface.
Add a recorder that subscribes to the existing topic. The producer does not need a new application-level connection for that consumer.
Topic types, compatible QoS and security permissions remain part of the integration contract.
Why teams choose DDS
Less plumbing. More control.
Build around the communication behaviour your system needs, with reusable mechanisms rather than a collection of custom protocols.
Timely communication
Move data when your system needs it.
Low-latency data paths and configurable resource limits support demanding real-time designs. End-to-end timing still depends on your platform, network and configuration.
Delivery on your terms
Choose the behaviour for each data flow.
Set reliability, history and durability to match the application. Use deadline and liveliness notifications to detect missing updates, and lifespan to expire stale samples.
Independent applications
Grow the system without rewiring it.
Discover compatible publishers and subscribers dynamically. Add consumers and develop components around shared interfaces, rather than lists of point-to-point connections.
Meaningful shared data
Agree on data, not just packets.
Typed topics define the information exchanged. Keys identify individual devices or objects; lifecycle information helps applications interpret their state.
Efficient distribution
Send useful data to the right consumers.
Combine one-to-many delivery, content filtering and suitable transport choices. Multicast can reduce repeated transmissions; local data paths depend on the implementation.
Controlled access
Protect communication by design.
DDS Security defines authentication, access control and cryptographic protection. Select an implementation that supports your requirements and configure its security policies.
Quality of service, made practical
Different data. Different delivery needs.
Not every update needs the same treatment. DDS lets you describe delivery requirements for each flow, rather than applying one rule to the whole system.
Illustrative choices, not fixed rules: sensor data can also require reliable delivery. Retention and recovery depend on the selected QoS, resource limits and implementation.
Choose the right communication model
Is DDS right for your architecture?
DDS is a strong candidate when distributed software needs a shared data model, multiple independent consumers and explicit control over delivery.
A strong fit when you need…
- Frequent data exchange with demanding latency or throughput requirements.
- Many-to-many communication across independently developed components.
- Different reliability, history and freshness requirements for different data.
- Interoperability across platforms and DDS implementations.
Plan for the engineering work.
DDS does not remove architectural decisions. You still need a data model, QoS profiles, discovery and network configuration, resource budgets and security policies.
Confirm the features and interoperability you need in the chosen products. System-level timing and safety are not guaranteed by selecting a protocol.
Approach | Often a good starting point for | What to consider |
|---|---|---|
DDS | Typed, many-to-many data exchange with fine-grained delivery control. | Invest in data modelling and QoS; validate the target deployment. |
MQTT | Broker-based telemetry and device-to-service messaging. | Plan broker availability and application-level data semantics. |
HTTP / REST | Web-facing resources and straightforward request–response APIs. | Continuous streams and unsolicited updates need additional mechanisms. |
Custom sockets | A tightly scoped protocol with specific constraints. | Your team owns framing, discovery, delivery behaviour and long-term maintenance. |
From the standard to working systems
One model. Many demanding applications.
Explore how DDS connects embedded devices, processing and control across different industries.
Put DDS to work with eProsima
Choose the foundation for your system.
Start with your production requirements: communication capabilities, platform constraints, functional safety and the support your team needs.
Professional deployments
Fast DDS Pro
Advanced communication capabilities, professional tools and direct engineering support for demanding distributed systems.
Safety-critical & embedded
Safe DDS
A purpose-built DDS implementation for constrained and safety-critical systems, with a safety-oriented development foundation.
Open source
Fast DDS
The open-source DDS implementation for building interoperable applications and exploring the DDS communication model.
Talk to a middleware expert
Let’s talk about your architecture.
Tell us what you need to connect. We can help you assess DDS, define your data interfaces and choose the right implementation.
Architecture and communication requirements.
Data models, QoS and integration.
Product selection and professional support.
