Overview of The OMG Data Distribution Service: Douglas C. Schmidt & Jeff Parsons

Overview of the OMG
Data Distribution Service
Douglas C. Schmidt & Jeff Parsons

{schmidt,parsons}@dre.vanderbilt.edu
http://www.dre.vanderbilt.edu/~schmidt/
Professor of EECS Vanderbilt

University Nashville, Tennessee
Tutorial on DDS Douglas C. Schmidt
Past R&D Successes: Platform-centric Systems

From this design paradigm…
Air
Nav Frame WTS
Legacy DoD systems are designed to be:
AP FLIR
• Stovepiped
GPS IFF • Proprietary
• Brittle & non-adaptive
• Expensive to develop & evolve
Cyclic
Exec • Vulnerable
2 break nearly anything & everything

Problem: Small changes can
Past R&D Successes: Platform-centric Systems

…and this operation paradigm…
Real-time QoS requirements for

Utility “Curve”
platform-centric DoD systems:
• Ensure end-to-end QoS, e.g.,
Utility
“Broken” “Works”
• Minimize latency, jitter, & footprint
• Bound priority inversions
• Allocate & manage resources Resources
statically
“Harder” Requirements
Problem: Lack of any resource3 can break nearly anything & everything
Past R&D Successes: Network-centric Systems

…to this design paradigm…
Today’s leading-edge DoD systems are

Air
Frame
AP Nav WTS
designed to be:
• Layered & componentized
Event
Channel
Replication
Service • More standard & COTS
• Robust to expected failures & adaptive
GPS IFF FLIR for non-critical tasks
Object Request Broker • Expensive to evolve & retarget
• Vulnerable
Problem: Unanticipated4 changes can break many things

…and this operational paradigm…
Applications Applications
Interceptor Sys Cond Sys Cond Sys Cond Sys Cond Interceptor
Middleware Middleware
Mechanism & Property
} {
Workload & Managers Workload &
Replicas Replicas
Local Connections & Connections & Local

Resource priority bands priority bands Resource
Managers QoS Contracts QoS Contracts Managers
CPU & memory CPU & memory
Network latency Network latency
& bandwidth & bandwidth
Endsystem Endsystem
Adaptive 5
Real-time Middleware

…and this operational paradigm…
Problem: Network-centricity is an
Desired afterthought in today’s systems
Utility
Curve
“Working
Utility
Range”
Resources
“Softer” Requirements
6
Case Study: QoS-enabled Publish/Subscribe

Technologies for Tactical Information Management
Coordination Feedback &
Of Multiple UAVs Control
Dynamic Mission
Replanning
Image Processing
& Tracking
DARPA PCES Capstone demo, 4/14/05, White Sands Missile Range

8
Case Study: QoS-enabled Publish/Subscribe

Technologies for Tactical Information Management
Coordination Feedback &
Of Multiple UAVs Control
Dynamic Mission
Replanning
Image Processing
& Tracking
Asynchronous
Event Handling Asynchronous
Transfer of
Physical Control
Memory
Access Synchronization
Memory
Management Scheduling
Modeling Tools Real-time JVMs Model Checking Real-time ORBs Aspect Languages
9
Limitations with Demo’d PCES

Information Management Technologies
• Shooter information management was based on Real-time Info to

platform-centric Real-time CORBA & Real-time Cockpit
CORBA Event Service Real-time Event
• Well-suited for point-to-point & static pub/sub Service
command processing over wireline networks
Object Request
• e.g., statically provisioned QoS policies Broker
• Poorly suited for dynamic pub/sub info
dissemination to multiple nodes in MANETs Tactical
• e.g., too many layers, excessive time/space Network & RTOS
overhead, inflexible QoS policies & pub/sub
model, etc.
Problem: Net-centricity is
10afterthought in platform-centric
Limitations with Demo’d PCES

Information Management Technologies
Track
Processing • C2 & C4ISR information management
Java Messaging
based on J2EE & Java Messaging
Service Service (JMS)
• Best suited for operational
J2EE
Middleware
enterprise environments
• e.g., large data centers connect
Enterprise via wireline networks
Network & OS • Poorly suited for tactical
environments
• e.g., lack of QoS policies &
RTOS integration, extremely
high time/space overhead
Problem: Enterprise technologies

11 are ill suited for tactical systems
Our R&D Goal: Evaluate QoS-enabled Info

Brokering for Tactical Systems
• Solutions must function properly where

• Communication bandwidth is limited/variable
• Connectivity is intermittent
• Connections are noisy
• Processing & storage capacity are limited
• Power & weight limits affect usage patterns
• Unanticipated workflows are common
• Dynamic network topology & membership changes are
frequent
• Ideally, solutions should be COTS, standard, & integrate
with heterogeneous legacy systems
Goal is “better than best-effort,”

12 subject to resource constraints…
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard Topic
• e.g., fewer layers, less R
overhead
Data Data
Writer Reader
R R
Publisher Subscriber
RT Info to Cockpit &

Track Processing
DDS Pub/Sub
Infrastructure
Tactical
Network & RTOS
13
pub/sub standard Topic NEW TOPIC
overhead
• DDS provides meta-events for Data
Writer
Data
Reader
detecting dynamic changes R R
NEW
SUBSCRIBER
NEW
PUBLISHER
14
pub/sub standard HISTORY Topic RESOURCE LIMITS
overhead
• DDS provides meta-events for Data
Writer
S1 Data
Reader
detecting dynamic changes R S2
R
S3
• DDS provides policies for
S4
specifying many QoS
S5
requirements of tactical
Publisher S6 Subscriber
information management
S7
systems, e.g.,
• Establish contracts that LATENCY
precisely specify a wide
variety of QoS policies at
multiple system layers
S7
X
S7 S6 S5 S4 S3 S2 S1
COHERENCY
RELIABILITY
15
DESTINATION
pub/sub standard Topic FILTER
overhead
• DDS provides meta-events for Data S1 Data
Writer SOURCE Reader
detecting dynamic changes R S2
FILTER R
• DDS provides policies for S3
specifying many QoS S4
requirements of tactical S5
information management S6
systems, e.g., S7
• Establish contracts that

precisely specify a wide
variety of QoS policies at TIME-BASED
multiple system layers FILTER
• Move processing closer to
data
16
DDS Architectural Elements

Data-Centric Publish-Subscribe Data Local Reconstruction Layer (DLRL)
(DCPS) – The upper layer APIs that define how to
– The lower layer APIs apps can use to build a local object cache so apps can
exchange topic data with other DDS- access topic data as if it were local
enabled apps according to designated
QoS policies
• DDS spec only defines policies & interfaces between application & service
• Doesn’t address protocols & techniques for different actors implementing the service
• Doesn’t address management of internal DDS resources
18
DDS Application Architecture
The Application
Application
DLRL
{
Application
DLRL
Application
DLRL
Application
DLRL
DCPS
Communication
19
DDS Domains & Domain Participants

• The domain is the basic construct used to bind individual applications together
for communication
Domain 2 Domain 3
• Like a VPN
3
1 1
Node Node Node
2 3
1
1
Node Node Node
DomainParticipant
Domain20
1
DCPS Entities
DCPS Entities include • Data can be accessed in two ways
– Topics – Wait-based (synchronous calls)
• Typed data – Listener-based (asynchronous callbacks)
– Publishers • Sophisticated support for filtering
• Contain DataWriters – e.g., Topic, Content-FilteredTopic, or
– Subscribers MultiTopic
• Contain DataReaders • Configurable via (many) QoS policies
– DomainParticipants
Topic Topic Topic
• Entry points
Domain
Participant
Data Data Data Data Data Data
Reader Writer Writer Reader Reader Writer
Subscriber Publisher Subscriber Publisher
Data Domain
21
QoS Policies Supported by DDS

• DCPS entities (i.e., topics, data readers/writers) configurable via QoS policies
• QoS tailored to data distribution in tactical information systems
– DEADLINE – RELIABILITY (BEST_EFFORT,
• Establishes contract regarding RELIABLE)
rate at which periodic data is • Enables use of real-time
refreshed transports for data
– LATENCY_BUDGET – HISTORY (KEEP_LAST, KEEP_ALL)
• Controls which (of multiple) data
• Establishes guidelines for
values are delivered
acceptable end-to-end delays
– DURABILITY (VOLATILE,
– TIME_BASED_FILTER TRANSIENT, PERSISTENT)
• Mediates exchanges between • Determines if data outlives time
slow consumers & fast producers when they are written
– RESOURCE_LIMITS – … and many more …
• Controls resources utilized by
service
• Request/offered compatibility checked by DDS
22
Best Effort Reliability QoS in DDS

QoS Reliability = BEST_EFFORT Subscriber
Subscriber
Publisher
Subscriber
Notification of new data objects

deadline timeout
time-based filter
no notification notification time
• Very predictable
• Data is sent without reply
• Publishers and subscribers match and obey QoS Deadline policy settings
• Time-based Filter QoS policy gives bandwidth control
23
Reliable QoS in DDS

QoS Reliability = RELIABLE
Topic
history R
Data S1 Data
Writer Reader
R S2
R
S3
S4
S5
Publisher S6 Subscriber
S7
S7 S6 S5 S4 S3 S2 S1
Ordered instance delivery is guaranteed
24
Tradeoff Between Reliability & Determinism

QoS Reliability = BEST_EFFORT
• Can’t have reliability and determinism.
• Best effort mode for streaming data.
X • No retries of dropped packets.
• Minimizes latency.
• Reliable mode for commands & events.
• Retry dropped packets until timeout.
• Every packet received in order.
QoS Reliability = RELIABLE • Speculative cache mechanism.
X • DDS reliability is tunable.

X • Can be adjusted per subscription.
25
All QoS Policies in DDS

• Deadline • Partition
• Destination Order • Presentation
• Durability • Reader Data Lifecycle
• Entity Factory • Reliability
• Group Data • Resource Limits
• History • Time-Based Filter
• Latency Budget • Topic Data
• Lifespan • Transport Priority
• Liveliness • User Data
• Ownership • Writer Data Lifecycle
• Ownership Strength
26
Single vs. Multiple Domain Systems
27
Data Writers & Publishers

• Data Writers are the primary access
point for an application to publish data
into a DDS data domain
• The Publisher entity is a container to
group together individual Data Writers
• User applications
– Associate Data Writers with Topics
– Provide data to Data Writers
– Data is typically defined using OMG
IDL
• It can therefore be as strongly
or weakly typed as you desire
28
Data Readers & Subscribers

• A Data Reader is the primary access
point for an application to access data
that has been received by a Subscriber
• Subscriber is used to group together
Data Readers
• Subscribers & Data Readers can have
their own QoS policies
• User applications
– Associate Data Readers with Topics
– Receive data from Data Readers
using Listeners (async) or Wait-Sets
(sync)
29
Types & Keys

• A DDS Type is represented by a collection of data items.
– e.g. “IDL struct” in the CORBA PSM
struct AnalogSensor {
string sensor_id; // key
float value; // other sensor data
};
• A subset of the collection is designated as the Key.
– The Key can be indicated by IDL annotation in CORBA PSM, e.g.,
#pragma DDS_KEY AnalogSensor::sensor_id
• It’s manipulated by means of automatically-generated typed interfaces.
– IDL compiler may be used in CORBA PSM implementation
• A Type is associated with generated code:
– AnalogSensorDataWriter // write values
– AnalogSensorDataReader // read values
– AnalogSensorType // can register itself with Domain
30
Topics
• A DDS Topic is the connection
between publishers & Domain
ID 35
subscribers.
• A Topic is comprised of a Name Topic
and a Type.
name “MySensor”
– Name must be unique in the
Domain.
Type
– Many Topics can have the
same Type. name “AnalogSensor”
• Provision is made for content- string sensor_id [ key ]
based subscriptions.
– MultiTopics correspond to float value
SQL join
– Content-Filtered Topics
correspond to SQL select.
31
Topic-Based Publish/Subscribe
Pressure
Temperature
• DataWriter is bound (at creation time) to a single Topic

• DataReader is bound (at creation time) with one or more topics (Topic,
ContentFilteredTopic, or MultiTopic)
– ContentFilteredTopic & MultiTopic provide means for content-based
subscriptions & “joins”, respectively
32
Subscription = Topic + DataReader
application
Data Data Data

Reader Reader Reader QoS
Topic 1 Topic 2 Topic n QoS
subscriber subscriber QoS
33
Content-based Subscriptions
• ContentFilteredTopic (like a DB-selection)

– Enables subscriber to only receive data-updates whose value
verifies a condition.
– e.g. subscribe to “Pressure” of type AnalogData
– where “value > 200”
• MultiTopic (like a DB-join operation)
– Enables subscription to multiple topics & re-arrangement of the data-
format
– e.g. combine subscription to “Pressure” & “Temperature” & re-
arrange the data into a new type:
struct { float pres; float temp; };
34
DDS Content-Filtered Topics

Topic Instances in Domain
Instance 1 Value = 249
Instance 2 Value = 230 Content-Filtered

Topic
Topic
Filter Expression:
Instance 5 Value = 258 Value > 260
Instance 6 Value = 261 Expression Params
Filter Expression and Expression Params determine which Topic instances the Subscriber receives.
35
DDS MultiTopic Subscriptions

Topic Topic Topic Topic
MultiTopic
Domain Participant Domain Participant
Data Data Data Data

Reader Reader Reader Reader
Subscriber Subscriber Subscriber
MultiTopics can combine, filter, and rearrange data from multiple Topics.
36
Example: Create Domain Participant

• DomainParticipant object acts as factory for Publisher, Subscriber,
Topic and MultiTopic entity objects
// used to identify the participant

DomainId_t domain_id = ...;
// get the singleton factory instance

DomainParticipantFactory_var dpf =
DomainParticipantFactory::get_instance ();
// create domain participant from factory

DomainParticipant_var dp =
dpf->create_participant (domain_id,
PARTICIPANT_QOS_DEFAULT,
NULL);
37
Example: Create Topic
……
// register the data type associated with the topic
FooDataType foo_dt;
foo_dt.register_type (dp,
“Foo”);
// create a topic
Topic_var foo_topic =
dp->create_topic (“Foo_topic”, //topic name
“Foo”, // type name
TOPIC_QOS_DEFAULT, // Qos policy
NULL); // topic listener
38
Example: Create Subscriber and DataReader

……
// create a subscriber from the domain participant
SubscriberQos sQos;
dp->get_default_subscriber_qos (sQos);
Subscriber_var s =
dp->create_subscriber (sQos,
NULL);
// create a data reader from the subscriber
// and associate it with the created topic
DataReader_var reader =
s->create_datareader (foo_topic.in (),
DATAREADER_QOS_DEFAULT,
NULL);
FooDataReader_var foo_reader =
FooDataReader::_narrow (reader.in ());
39
Example: Create Publisher and DataWriter

……
// create a publisher from the domain participant
PublisherQos pQos;
dp->get_default_publisher_qos (pQos);
Publisher_var p =
dp->create_publisher (pQos, NULL);
// create a data writer from the publisher

// and associate it with the created topic
DataWriter_var writer =
p->create_datawriter (foo_topic.in (), DATAWRITER_QOS_DEFAULT,
NULL);
// narrow down to specific data writer

FooDataWriter_var foo_writer =
FooDataWriter::_narrow (writer);
// publish user-defined data

Foo foo_data;
foo_writer->write (foo_data);
40
How to Get Data (Async Listener-based)

Listener_var subscriber_listener = new MyListener();
foo_reader->set_listener(subscriber_listener);
MyListener::on_data_available(DataReader reader)
{
FooSeq_var received_data;
SampleInfoSeq_var sample_info;
reader->take(received_data.out (),
sample_info.out (),
ANY_SAMPLE_STATE,
ANY_LIFECYCLE_STATE);
// Use received_data
……
}
41
How to Get Data (Sync Wait-based)

Condition_var foo_condition =
reader->create_readcondition(ANY_SAMPLE_STATE,
ANY_LIFECYCLE_STATE);
WaitSet waitset;
waitset->attach_condition(foo_condition);
ConditionSeq_var active_conditions;
Duration_t timeout = {3,0};
waitset->wait(active_conditions.out (), timeout);
...
FooSeq_var received_data;
SampleInfoSeq_var sample_info;
reader->take_w_condition(received_data.out (),
sample_info.out (),
foo_condition);
// Use received_data
42
Benchmark Scenario
• Two processes perform IPC in which a client initiates a request to transmit
a number of bytes to the server along with a seq_num (pubmessage), &
the server simply replies with the same seq_num (ackmessage).
– The invocation is essentially a two-way call, i.e., the
client/server waits for the request to be completed.
• The client & server are collocated.
• DDS & JMS provides topic-based pub/sub model.
• Notification Service uses push model.
• SOAP uses p2p schema-based model.
43
Testbed Configuration
• Hostname
blade14.isislab.vanderbilt.edu
• OS version (uname -a)
Linux version 2.6.14-1.1637_FC4smp ([email protected])
• GCC Version
g++ (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-47.fc4)
• CPU info
Intel(R) Xeon(TM) CPU 2.80GHz w/ 1GB ram
44
Test Parameters
// Complex Sequence Type
struct Inner { • Average round-trip latency &
string info; dispersion
long index; • Message types:
}; – sequence of bytes
typedef sequence<Inner> – sequence of complex type
InnerSeq;
• Lengths in powers of 2
struct Outer {
• Ack message of 4 bytes
long length;
• 100 primer iterations
InnerSeq nested_member;
• 10,000 stats iterations
};
typedef sequence<Outer>
ComplexSeq;
45
Roundtrip Latency Results (1/2)

DDS/GSOAP/JMS/Notification Service Comparison - Latency
100000
DDS1 DDS2
DDS3 GSOAP
10000
JMS Notification Service
Avg. Latency (usecs)
1000
100
10
4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384
Message Size (bytes)
46
Roundtrip Latency Results (2/2)
47
Roundtrip Latency Results Analysis
• From the results we can see that DDS has significantly better
performance than other SOA & pub/sub services.
• Although there is a wide variation in the performance of the
DDS implementations, they are all at least twice as fast as
other pub/sub services.
48
Encoding/Decoding Benchmarks
• Measured overhead and dispersion of

– encoding C++ data types for transmission
– decoding C++ data types from transmission
• DDS3 and GSOAP implementations compared
• Same data types, platform, compiler and test parameters as
for roundtrip latency benchmarks
49
Encoding/Decoding Results (1/2)
DDS/GSOAP Comparison - Encoding Overhead
1000000
DDS3 Byte Sequence

100000
DDS3 Complex Sequence
GSOAP Byte Sequence
10000
GSOAP Complex Sequence
1000
Time (usecs)
100
10
0.1
0.01
4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384
Sequence Length
50
Encoding/Decoding Results (2/2)
DDS/GSOAP Comparison - Decoding Overhead
1000000
DDS3 Byte Sequence
DDS3 Complex Sequence
100000
GSOAP Byte Sequence
GSOAP Complex Sequence
10000
Time (usecs)
1000
100
10
1
4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384
Sequence Length
51
Encoding/Decoding Results Analysis

• Slowest DDS implementation is compared with GSOAP.
• DDS is faster.
– Almost always by a factor of 10 or more.
– GSOAP is encoding XML strings.
• Difference is larger for byte sequences.
– DDS implementation has optimization for byte seq.
• Encodes sequence as a single block – no iteration.
– GSOAP always iterates to encode sequences.
• Jitter discontinuities occur at consistent payload sizes.
52
Summary of DCPS features

subscribers
DDS
publishers
Information consumer subscribe to information of interest
Information producer publish information
DDS matches & routes relevant info to interested subscribers
• Efficient Publish/Subscribe interfaces

• QoS suitable for real-time systems
– deadlines, levels of reliability, latency, resource usage, time-based filter
• Listener & wait-based data access suits different application styles
• Support for content-based subscriptions
• Support for data-ownership
• Support for history & persistence of data-modifications
53
Data Local Reconstruction Layer (DLRL)
Track
Track 3D_Track DLRL
Cache
Track_Topic 3D -Track DCPS
54
Goals of DLRL
• Data Local Reconstruction Layer (DLRL) model is local to an application
• “Object-oriented” access to data
• Application developers can
– describe classes with their methods, data fields, & relations
– attach some of those data fields to DCPS entities
– manipulate these objects (i.e., create, read, write, delete) using native
language constructs
– activate attached DCPS entities to update objects
– have these objects managed in a cache
• Like a mapping or binding (intuition only)
55
DLRL Objects
• DLRL objects are (native) language objects with:
– data members and methods
• Only the data members are relevant to data distribution; they can
be:
– attributes, i.e., values
– relations, i.e., reference other objects
– plain local data members (i.e., not known or involved in data
distribution) are also supported
• DLRL classes can be organised by inheritance
• DLRL objects maps to one or more DCPS Topics
56
DLRL Object Examples
Track tracks a_radar Radar
x : real * 0..1
y : real
comments [*] : string
w : integer
Track3D
z : real
57
DLRL Radar Example

Track tracks a_radar Radar
x : real * 0..1
y : real
comments [*] : string TRACK_TOPIC
w : integer
Class Oid x y radar
Track 1 100 200 11
Track3D 2 102 201 11
COMMENTS_TOPIC
Track3D
Class Oid index comments
z : real Track 1 0 a comment
Track 1 1 another comment
T3D_TOPIC RADAR_TOPIC RADAR_TRACKS_TOPIC

Oid z Oid R_Oid index T_Class T_Oid
2 300 11 11 0 Track 1
58 11 1 Track3D 2
Evaluating DDS
Pros
• Low overhead & efficient use of transport bandwidth
– e.g., less features/overhead than CORBA in the main request path
• Dynamically scalable & highly flexible
– e.g., can receive notification about all sorts of meta-events, such as new
topics, publishers, subscribers, etc.
• Supports one-to-one, one-to-many, many-to-one, & many-to-many
communication
• Large number of configuration parameters & QoS policies that give developers
extensive control of message transmission & reception
Cons
• DDS is not well suited to request-reply services, file transfer, & transaction
processing
• The data-distribution paradigm is not optimized for sending a request & waiting
for a reply
• Implementations don’t yet cover the entire spec
• Lack of interoperability between different vendor’s implementations
59
Comparing CORBA with DDS
Distributed object Distributed data

• Client/server • Publish/subscribe
• Remote method calls • Multicast data
• Reliable transport • Configurable QoS
Best for Best for
• Remote command processing • Quick dissemination to many nodes
• File transfer • Dynamic nets
• Synchronous transactions • Flexible delivery requirements
DDS & CORBA address different needs

Complex systems
60 often need both…

Overview of The OMG Data Distribution Service: Douglas C. Schmidt & Jeff Parsons

Uploaded by

Copyright:

Available Formats

Overview of The OMG Data Distribution Service: Douglas C. Schmidt & Jeff Parsons

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Overview of The OMG Data Distribution Service: Douglas C. Schmidt & Jeff Parsons

Uploaded by

Copyright:

Available Formats

Overview of the OMG

Data Distribution Service

Douglas C. Schmidt & Jeff Parsons

Professor of EECS Vanderbilt

Past R&D Successes: Platform-centric Systems

2 break nearly anything & everything

Past R&D Successes: Platform-centric Systems

Real-time QoS requirements for

Past R&D Successes: Network-centric Systems

Today’s leading-edge DoD systems are

Past R&D Successes: Network-centric Systems

Local Connections & Connections & Local

Past R&D Successes: Network-centric Systems

Case Study: QoS-enabled Publish/Subscribe

DARPA PCES Capstone demo, 4/14/05, White Sands Missile Range

Case Study: QoS-enabled Publish/Subscribe

Limitations with Demo’d PCES

• Shooter information management was based on Real-time Info to

Limitations with Demo’d PCES

Problem: Enterprise technologies

Our R&D Goal: Evaluate QoS-enabled Info

• Solutions must function properly where

Goal is “better than best-effort,”

RT Info to Cockpit &

specifying many QoS S4

• Establish contracts that

DDS Architectural Elements

DDS Application Architecture

DDS Domains & Domain Participants

Subscriber Publisher Subscriber Publisher

QoS Policies Supported by DDS

• Request/offered compatibility checked by DDS

Best Effort Reliability QoS in DDS

Notification of new data objects

no notification notification time

Reliable QoS in DDS

Ordered instance delivery is guaranteed

Tradeoff Between Reliability & Determinism

X • DDS reliability is tunable.

All QoS Policies in DDS

Single vs. Multiple Domain Systems

Data Writers & Publishers

Data Readers & Subscribers

Types & Keys

• DataWriter is bound (at creation time) to a single Topic

Subscription = Topic + DataReader

Data Data Data

Topic 1 Topic 2 Topic n QoS

subscriber subscriber QoS

• ContentFilteredTopic (like a DB-selection)

DDS Content-Filtered Topics

Instance 1 Value = 249

Instance 2 Value = 230 Content-Filtered

Instance 6 Value = 261 Expression Params

Instance 7 Value = 259

DDS MultiTopic Subscriptions

Domain Participant Domain Participant

Data Data Data Data

Subscriber Subscriber Subscriber