1. No category

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…
Nav
Air
Frame
WTS
AP
FLIR
GPS
IFF
Cyclic
Exec
Legacy DoD systems are designed to be:
• Stovepiped
• Proprietary
• Brittle & non-adaptive
• Expensive to develop & evolve
• Vulnerable
2
Problem: Small changes can break
nearly anything & everything
Tutorial on DDS
Douglas C. Schmidt
Past R&D Successes: Platform-centric Systems
…and this operation paradigm…
Utility “Curve”
Utility
Real-time QoS requirements for
platform-centric DoD systems:
• Ensure end-to-end QoS, e.g.,
• Minimize latency, jitter, & footprint
• Bound priority inversions
• Allocate & manage resources
statically
“Broken”
“Works”
Resources
“Harder” Requirements
3 break nearly anything & everything
Problem: Lack of any resource can
Tutorial on DDS
Douglas C. Schmidt
Past R&D Successes: Network-centric Systems
…to this design paradigm…
Air
Frame
AP
Event
Channel
GPS
Nav
WTS
Replication
Service
IFF
FLIR
Object Request Broker
Today’s leading-edge DoD systems are
designed to be:
• Layered & componentized
• More standard & COTS
• Robust to expected failures & adaptive
for non-critical tasks
• Expensive to evolve & retarget
• Vulnerable
Problem: Unanticipated changes
can break many things
4
Tutorial on DDS
Douglas C. Schmidt
Past R&D Successes: Network-centric Systems
…and this operational paradigm…
Applications
Applications
Interceptor
Sys Cond
Sys Cond
Sys Cond
Sys Cond
Middleware
Workload &
Replicas
Local
Resource
Managers
Connections &
priority bands
}
Mechanism & Property
Managers
QoS Contracts
Interceptor
Middleware
{
Workload &
Replicas
Connections &
priority bands
QoS Contracts
CPU & memory
CPU & memory
Network latency
& bandwidth
Network latency
& bandwidth
Local
Resource
Managers
Endsystem
Endsystem
Adaptive Real-time
Middleware
5
Tutorial on DDS
Douglas C. Schmidt
Past R&D Successes: Network-centric Systems
…and this operational paradigm…
Utility
Desired
Utility
Curve
Problem: Network-centricity is an
afterthought in today’s systems
“Working
Range”
Resources
“Softer” Requirements
6
Tutorial on DDS
Douglas C. Schmidt
Case Study: QoS-enabled Publish/Subscribe
Technologies for Tactical Information Management
Coordination
Of Multiple UAVs
Feedback &
Control
Dynamic Mission
Replanning
Image Processing
& Tracking
DARPA PCES Capstone demo, 4/14/05, White Sands Missile Range
8
Tutorial on DDS
Douglas C. Schmidt
Case Study: QoS-enabled Publish/Subscribe
Technologies for Tactical Information Management
Coordination
Of Multiple UAVs
Feedback &
Control
Dynamic Mission
Replanning
Image Processing
& Tracking
Asynchronous
Event Handling
Physical
Memory
Access
Memory
Management
Modeling Tools
Asynchronous
Transfer of
Control
Synchronization
Scheduling
Real-time JVMs
Model Checking9 Real-time ORBs
Aspect Languages
Tutorial on DDS
Douglas C. Schmidt
Limitations with Demo’d PCES
Information Management Technologies
• Shooter information management was based on
platform-centric Real-time CORBA & Real-time
CORBA Event Service
• Well-suited for point-to-point & static pub/sub
command processing over wireline networks
• e.g., statically provisioned QoS policies
• Poorly suited for dynamic pub/sub info
dissemination to multiple nodes in MANETs
• e.g., too many layers, excessive time/space
overhead, inflexible QoS policies & pub/sub
model, etc.
Real-time Info to
Cockpit
Real-time Event
Service
Object Request
Broker
Tactical
Network & RTOS
Problem: Net-centricity is afterthought
10 in platform-centric technologies
Tutorial on DDS
Douglas C. Schmidt
Limitations with Demo’d PCES
Information Management Technologies
Track
Processing
• C2 & C4ISR information
management based on J2EE &
Java Messaging
Java Messaging Service (JMS)
Service
• Best suited for operational
J2EE
enterprise environments
Middleware
• e.g., large data centers
Enterprise
connect via wireline
Network & OS
networks
• Poorly suited for tactical
environments
• e.g., lack of QoS policies &
RTOS integration, extremely
high time/space overhead
Problem: Enterprise technologies
11are ill suited for tactical systems
Tutorial on DDS
Douglas C. Schmidt
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…
Tutorial on DDS
Douglas C. Schmidt
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
• e.g., fewer layers, less
overhead
Topic
R
Data
Writer
R
Data
Reader
R
Publisher
Subscriber
RT Info to Cockpit &
Track Processing
DDS Pub/Sub
Infrastructure
Tactical
Network & RTOS
13
Tutorial on DDS
Douglas C. Schmidt
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
• e.g., fewer layers, less
overhead
• DDS provides meta-events for
detecting dynamic changes
Topic
NEW TOPIC
R
Data
Writer
R
Data
Reader
R
NEW
SUBSCRIBER
Publisher
Subscriber
NEW
PUBLISHER
14
Tutorial on DDS
Douglas C. Schmidt
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
• e.g., fewer layers, less
overhead
• DDS provides meta-events for
detecting dynamic changes
• DDS provides policies for
specifying many QoS
requirements of tactical
information management
systems, e.g.,
• Establish contracts that
precisely specify a wide
variety of QoS policies at
multiple system layers
Topic
HISTORY
RESOURCE LIMITS
R
Data
Writer
R
S1
Data
Reader
R
S2
S3
S4
S5
Publisher
Subscriber
S6
S7
LATENCY
S7
X
S7
S6
S5
S4
S3
S2
S1
COHERENCY
RELIABILITY
15
Tutorial on DDS
Douglas C. Schmidt
Overview of the Data Distribution Service (DDS)
• DDS is an highly efficient OMG
pub/sub standard
• e.g., fewer layers, less
overhead
• DDS provides meta-events for
detecting dynamic changes
• DDS provides policies for
specifying many QoS
requirements of tactical
information management
systems, e.g.,
• Establish contracts that
precisely specify a wide
variety of QoS policies at
multiple system layers
• Move processing closer to
data
DESTINATION
Topic
FILTER
R
Data
Writer
R
S1
S2
SOURCE
FILTER
Data
Reader
R
S3
S4
S5
Publisher
Subscriber
S6
S7
TIME-BASED
FILTER
16
Tutorial on DDS
Douglas C. Schmidt
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 DDSaccess 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
Tutorial on DDS
Douglas C. Schmidt
DDS Application Architecture
{
The Application
Application
DLRL
Application
Application
DLRL
DLRL
DCPS
Communication
19
Application
DLRL
Tutorial on DDS
Douglas C. Schmidt
DDS Domains & Domain Participants
• The domain is the basic construct used to bind individual applications together
for communication
Domain 3
Domain 2
• Like a VPN
2
3
1
1
Node
Node
2
1
Node
3
1
Node
Node
DomainParticipant
Domain 1 20
Node
Tutorial on DDS
Douglas C. Schmidt
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
MultiTopic
– Subscribers
• Configurable via (many) QoS policies
• Contain DataReaders
– DomainParticipants
Topic
• Entry points
Data
Reader
Domain
Participant
Subscriber
Data
Writer
Topic
Data
Writer
Topic
Data
Reader
Publisher
Data Domain
21
Data
Reader
Subscriber
Data
Writer
Publisher
Tutorial on DDS
Douglas C. Schmidt
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,
RELIABLE)
• Establishes contract regarding
rate at which periodic data is
refreshed
• Enables use of real-time
transports for data
– LATENCY_BUDGET
– HISTORY (KEEP_LAST,
KEEP_ALL)
• Establishes guidelines for
acceptable end-to-end delays
• Controls which (of multiple)
data values are delivered
– TIME_BASED_FILTER
• Mediates exchanges between
slow consumers & fast producers
– DURABILITY (VOLATILE,
TRANSIENT, PERSISTENT)
• Determines if data outlives
time when they are written
– RESOURCE_LIMITS
• Controls resources utilized by
service
– … and many more …
• Request/offered compatibility checked by DDS
22
Tutorial on DDS
Douglas C. Schmidt
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
• 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
time
Tutorial on DDS
Douglas C. Schmidt
Reliable QoS in DDS
QoS Reliability = RELIABLE
Topic
history
Data
Writer
R
R
S1
Data
Reader
R
S2
S3
S4
S5
Publisher
Subscriber
S6
S7
S7
S6
S5
S4
S3
S2
Ordered instance delivery is guaranteed
24
S1
Tutorial on DDS
Douglas C. Schmidt
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.
• Speculative cache mechanism.
QoS Reliability = RELIABLE
X
X
• DDS reliability is tunable.
• Can be adjusted per subscription.
25
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
Single vs. Multiple Domain Systems
27
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
Topics
• A DDS Topic is the connection
between publishers &
subscribers.
• A Topic is comprised of a Name
and a Type.
– Name must be unique in the
Domain.
– Many Topics can have the
same Type.
• Provision is made for contentbased subscriptions.
– MultiTopics correspond to
SQL join
– Content-Filtered Topics
correspond to SQL select.
Domain
ID
35
Topic
name
“MySensor”
Type
name
31
“AnalogSensor”
string
sensor_id
float
value
[ key ]
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
Subscription = Topic + DataReader
application
Data
Reader
Data
Reader
Data
Reader
QoS
Topic 1
Topic 2
Topic n
QoS
subscriber
QoS
subscriber
33
Tutorial on DDS
Douglas C. Schmidt
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 dataformat
– e.g. combine subscription to “Pressure” & “Temperature” & rearrange the data into a new type:
struct { float pres; float temp; };
34
Tutorial on DDS
Douglas C. Schmidt
DDS Content-Filtered Topics
Topic Instances in Domain
Instance 1
Value = 249
Instance 2
Value = 230
Instance 3
Value = 275
Instance 4
Value = 262
Instance 5
Value = 258
Filter Expression:
Value > 260
Instance 6
Value = 261
Expression Params
Instance 7
Value = 259
Content-Filtered
Topic
Topic
Filter Expression and Expression Params determine which Topic instances the Subscriber receives.
35
Tutorial on DDS
Douglas C. Schmidt
DDS MultiTopic Subscriptions
Topic
Topic
Topic
Topic
MultiTopic
Domain Participant
Data
Reader
Subscriber
Domain Participant
Data
Reader
Data
Reader
Data
Reader
Subscriber
Subscriber
MultiTopics can combine, filter, and rearrange data from multiple Topics.
36
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
Test Parameters
// Complex
Sequence Type
struct Inner {
string info;
long index;
};
typedef sequence<Inner>
InnerSeq;
struct Outer {
long length;
InnerSeq nested_member;
};
• Average round-trip latency &
dispersion
• Message types:
– sequence of bytes
– sequence of complex type
• Lengths in powers of 2
• Ack message of 4 bytes
• 100 primer iterations
• 10,000 stats iterations
typedef sequence<Outer>
ComplexSeq;
45
Tutorial on DDS
Douglas C. Schmidt
Roundtrip Latency Results (1/2)
DDS/GSOAP/JMS/Notification Service Comparison - Latency
Avg. Latency (usecs)
100000
10000
DDS1
DDS2
DDS3
GSOAP
JMS
Notification Service
1000
100
10
4
8
16
32
64
128
256
512
Message Size (bytes)
46
1024
2048
4096
8192
16384
Tutorial on DDS
Douglas C. Schmidt
Roundtrip Latency Results (2/2)
47
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
Encoding/Decoding Results (1/2)
DDS/GSOAP Comparison - Encoding Overhead
1000000
DDS3 Byte Sequence
100000
DDS3 Complex Sequence
GSOAP Byte Sequence
Time (usecs)
10000
GSOAP Complex Sequence
1000
100
10
1
0.1
0.01
4
8
16
32
64
128
256
512
Sequence Length
50
1024
2048
4096
8192
16384
Tutorial on DDS
Douglas C. Schmidt
Encoding/Decoding Results (2/2)
DDS/GSOAP Comparison - Decoding Overhead
1000000
DDS3 Byte Sequence
DDS3 Complex Sequence
100000
GSOAP Byte Sequence
Time (usecs)
GSOAP Complex Sequence
10000
1000
100
10
1
4
8
16
32
64
128
256
512
Sequence Length
51
1024
2048
4096
8192
16384
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
DDS
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
publishers
subscribers
Summary of DCPS features
Tutorial on DDS
Douglas C. Schmidt
Data Local Reconstruction Layer (DLRL)
Track
Track
3D_Track
DLRL
Cache
Track_Topic
3D -Track
54
DCPS
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
DLRL Object Examples
Track
tracks
a_radar
x : real
y : real
comments [*] : string
w : integer
*
0..1
Track3D
z : real
57
Radar
Tutorial on DDS
Douglas C. Schmidt
DLRL Radar Example
Track
tracks
a_radar
x : real
y : real
comments [*] : string
w : integer
*
0..1
Radar
TRACK_TOPIC
Class
Oid
x
y
radar
Track
1
100
200
11
Track3D
2
102
201
11
COMMENTS_TOPIC
Track3D
Class
z : real
T3D_TOPIC
z
Oid
2
300
11
comments
Track
1
0
a comment
Track
1
1
another comment
RADAR_TOPIC
Oid
Oid index
RADAR_TRACKS_TOPIC
R_Oid index T_Class T_Oid
58
11
0
Track
1
11
1
Track3D
2
Tutorial on DDS
Douglas C. Schmidt
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
Tutorial on DDS
Douglas C. Schmidt
Comparing CORBA with DDS
Distributed object
• Client/server
• Remote method calls
• Reliable transport
Best for
• Remote command processing
• File transfer
• Synchronous transactions
Distributed data
• Publish/subscribe
• Multicast data
• Configurable QoS
Best for
• Quick dissemination to many nodes
• Dynamic nets
• Flexible delivery requirements
DDS & CORBA address different needs
Complex systems
60 often need both…