Getting Started with OpenSplice DDS Community Ed.

OpenSplice DDS
Delivering Performance, Openness, and Freedom

Getting Started with
Angelo Corsaro, Ph.D.
Chief Technology Officer
OMG DDS SIG Co-Chair
angelo.corsaro@prismtech.com

the Community Ed.

OpenSplice DDS

Background

Addressing Data Distribution Challenges
DDS is standard designed to address the data-distribution challenges across
The OMG DDS Standard a wide class of Defense and Aerospace Applications
‣ Introduced in 2004 to address the Data
Distribution challenges faced by a wide
class of Defense and Aerospace
Applications
‣ Key requirement for the standard were its
ability to deliver very high performance while
seamlessly scaling from embedded to ultra-
large-scale deployments
‣ Today recommended by key administration
worldwide and widely adopted across
several different application domains, such
as, Automated Trading, Simulations, SCADA,
Telemetry, etc.

© 2009, PrismTech. All Rights Reserved

The OMG Data Distribution Service (DDS)

DDS v1.2 API Standard
‣ Language Independent, OS and HW architecture Application

independent Object/Relational Mapping

‣ DCPS. Standard API for Data-Centric, Topic- Data Local Reconstruction Layer (DLRL)

Based, Real-Time Publish/Subscribe
Content
‣
Ownership Durability
DLRL. Standard API for creating Object Views out Subscription

of collection of Topics Minimum Proﬁle

Data Centric Publish/Subscribe (DCPS)
DDSI/RTPS v2.1 Wire Protocol Standard
‣ Standard wire protocol allowing interoperability
Real-Time Publish/Subscribe Protocol

DDS Interoperability Wire Protocol
between different implementations of the DDS
standard UDP/IP

‣ Interoperability demonstrated among key DDS
vendors in March 2009

OpenSplice DDS Community Ed.
Features
Application ‣ OMG DDS v1.2 DCPS ‣ Networking
‣ Minimum Profile ‣ DDSI v2.1 Implementation
Content ‣ Content Subscription Profile ‣ Real-Time Networking

DDS v1.2
Ownership Durability
Subscription Implementation
‣ Durability Profile
‣ Ownership Profile
Minimum Proﬁle

Real-Time Pub/Sub (DCPS)

DDSI v2.1
Interoperable Wire Protocol
Real-Time Networking
(DDSI)
OMG DDS Standard Compliance
Networking Technology
DCPS Proﬁles DDSI/
UDP/IP DLRL
Minimum Content Ownership Durability RTPS

OpenSplice DDS
Yes Yes Yes Yes No Yes
Licensing Community Ed.

Other DDS (Best Case) Yes Partial Yes No* No Yes


Performance on Commodity HW
Throughput -./0/1/23' 456/'
Latency
#+(+%++' &&++%++'

$+(+%++' "*(%)+' ")(%&!' ""&%,&'&+++%++' Inter-Node Latency
!"#$%&#'

‣ 60 usec
"!+%++'
)"#%*)' "++%++'
)$,%$*'
!+(+%++'
)++%++'
Inter-Core Read-Latency
&'$($)$*+%

Proprietary Information - Distribution without Expressed Written Permission is Prohibited.
*!#%,&'

‣ 2 usec

!"#$%
,+(+%++' *++%++'
()(!%(*'

#++%++'
(+(+%++' &")&%+)' Inter-Core Latency
‣ <10 usec
$&"%,,'
$++%++'
&!(,%!)'

&+(+%++'
),,%$#' !++%++'
,*+%&)'
!,*%))'
,($%!+' (("%!"'
&&)%*$' $"%"$' ,+%($' ,++%++' HW:
(+%++'
)' &#' ,(' #!' &()' ($#' $&(' &+(!' (+!)' !+"#'
‣ Dell blade-server
!*$$,(*%-./*%
‣ Dual-core, Dual-CPU, AMD Opteron 2.4 Ghz
Test Scenario OS
‣ Linux 2.6.21-1.3194.fc7
‣ Single Threaded Application (multi-threaded networking service) Network
‣ 8192 bit message batches ‣ Gigabit Ethernet cards
‣ Dell PowerConnect 5324 switch

OpenSplice DDS

As Simple as it Gets

‣ DDS is based around the concept
of a fully distributed Global Data
Space (GDS)

Global Data Space

DDS


Space (GDS)
‣ Publishers and Subscribers can
join and leave the GDS at any time
Global Data Space

DDS


Publisher Subscriber
Space (GDS)
Subscriber
Publisher
Global Data Space


DDS


Space (GDS)
Subscriber
‣ Publishers and Subscribers Publisher
Global Data Space
express their intent to produce/
consume specific type of data,
e.g., Topics

DDS


Space (GDS)
Subscriber
‣ Publishers and Subscribers Publisher Global Data Space
express their intent to produce/
consume specific type of data,
e.g., Topics
Subscriber
‣ Data flows from Publisher to Publisher

Subscribers DDS


OpenSplice DDS

Deﬁning Data

DDS Topics
{Circle, Square, Triangle}
Topic
‣ Unit of information exchanged between
Publisher and Subscribers.
‣ An association between a unique name, a
type and a QoS setting {ShapeType} {...}

Topic Type.
struct ShapeType {
‣ Type describing the data associated with one long x;
or more Topics long y;
‣ A Topic type can have a key represented by an long shapesize;
string color;
arbitrary number of attributes };
‣ Expressed in IDL #pragma keylist ShapeType color


DDS Topics

Circle

struct ShapeType {
long x;
long y;
long shapesize; Topic QoS
string color;
};
#pragma keylist ShapeType color


DDS Topics

Triangle

struct ShapeType {
long x;
long y;
long shapesize; Topic QoS
string color;
};


DDS Topic Instances and Samples
Topic Instances
‣ Each key value identifies a unique Topic Instance,
‣ Topic’s instance lifetime can be explicitly
managed in DDS

Topic Samples
‣ The values assumed by a Topic Instance
over time are referred as Instance Sample
struct ShapeType {
long x;
long y;
long shapesize;
string color;
};

Topic/Instances/Samples Recap.
Topics Instances

Samples

ti tj tnow time

Content Filtering
X0 X1
X0 <= X <= X1
‣ DDS allows to specify content-
filtered Topics for which a subset
of SQL92 is used to express the
filter condition
Y0
‣ Content filters can be applied on
the entire content of the Topic Type Y0 <= Y <= Y1

‣ Content filters are applied by DDS
Y1
each time a new sample is
produced/delivered


Local Queries
‣ Subscribed Topics can be seen locally as “Tables”
‣ A subset of SQL92 can be used for performing queries on X0
multiple topics as well as natural joins
‣ Queries are Circle Topic
performed under Y0
color x y shapesize Y0
user control and red 57 62 50
provide a result that blue 90 85 50
Y0 <= Y <= Y1
depends on the yellow 30 25 50

current snapshot of SELECT * FROM ShapeType s
WHERE s.x > 25 AND s.y < 55 Y1
the system, e.g.,
samples currently color x y shapesize
available yellow 30 25 50


OpenSplice DDS

Organizing Data

DDS Partitions

‣ All DDS communication is Domain
Partition

happens within a Domain
‣ Domain can divided into Publisher
Subscriber

Partitions B

‣ Topics are published and m

subscribed across on or A F

Subscriber
more Partitions Publisher J
D C

K
E

Publisher
Subscriber


OpenSplice Network Partitions
‣ OpenSplice DDS allows to Publisher
Subscriber
define network partitions along "Red"
B
with DDS partitions
m

‣ Network partitions are bound to A F

a list of unicast/multicast Publisher J
"Green" Subscriber
network addresses D C

‣ Partition.Topic combination can K
E
"Yellow"
be mapped into OpenSplice
DDS Network Partitions Publisher
Subscriber
‣ Wildcards can be used when
defining the mapping, and in
Yellow.* => 224.1.1.1 Green.* => 224.1.1.2
case of multiple matches Green.E => 224.1.1.3
OpenSplice DDS will always
consider the best match


Network Partition (osplconf)


Partition Mapping (osplconf)


OpenSplice DDS

Quality of Service

Anatomy of a DDS Application

Topic
Topic
Topic
Samples
Samples
Instances Samples
Instances
Instances
121 62
1
21 62
1 22 62
1 22 62
1 23 63
1 23 63
DataReader
DataReader
1 21 62
2 20 61
1 22 62
2 19 60
1 23 63
DataReader
DataReader 2 20 61
2 20 61
2 19 60
2 19 60 DataWriter
DataWriter
DataReader
DataReader 3 25 70 3 25 71
25 3 25 74 3 26 77
3 26 77
DataWriter
DataWriter
3 25 70 3 25 71
25 3 25 74
struct TempSensor { 3 25 70 3 25 71
25 3 25 74 3 26 77
int tID;
float temp;
float humidity;
};
#pragma keylist TempSensor tID



Topic
Topic
Topic
Samples
Samples
Instances Samples
Instances
Instances
121 62
1
21 62
1 22 62
1 22 62
1 23 63
1 23 63
DataReader
DataReader
1 21 62
2 20 61
1 22 62
2 19 60
1 23 63
DataReader
DataReader 2 20 61
2 20 61
2 19 60
2 19 60 DataWriter
DataWriter
DataReader
DataReader 3 25 70 3 25 71
25 3 25 74 3 26 77
3 26 77
DataWriter
DataWriter
3 25 70 3 25 71
25 3 25 74
25 3 25 74 3 26 77
int tID;
float temp;
Arrows };
float humidity;

show #pragma keylist TempSensor tID

structural
relationship
s, not data- Subscriber Publisher
ﬂows Partition



Topic
Topic
Topic
Samples
Samples
Instances Samples
Instances
Instances
121 62
1
21 62
1 22 62
1 22 62
1 23 63
1 23 63
DataReader
DataReader
1 21 62
2 20 61
1 22 62
2 19 60
1 23 63
DataReader
DataReader 2 20 61
2 20 61
2 19 60
2 19 60 DataWriter
DataWriter
DataReader
DataReader 3 25 70 3 25 71
25 3 25 74 3 26 77
3 26 77
DataWriter
DataWriter
3 25 70 3 25 71
25 3 25 74
25 3 25 74 3 26 77
int tID;
float temp;
Arrows };
float humidity;

show #pragma keylist TempSensor tID

structural
relationship
s, not data- Subscriber Publisher
ﬂows Partition

Domain Participant

Domain

QoS Model
‣ QoS-Policies are used to control relevant
properties of OpenSplice DDS entities, Type Matching
QoS matching
such as: QoS QoS QoS QoS QoS QoS QoS

‣ Temporal Properties
‣ Priority
Topic
Name

‣ Durability ... DataWriter writes Type reads DataReader
...
...
‣ Availability DomainParticipant writes Type reads DataReader DomainParticipant
DataWriter
‣ ... Name

‣ Some QoS-Policies are matched based on
Topic

QoS QoS QoS
a Request vs. Offered Model thus QoS-
enforcement

‣ Publications and Subscriptions match only if the declared vs. requested QoS are compatible
‣ e.g., it is not possible to match a publisher which delivers data unreliably with a subscriber which requires reliability

QoS Policies
QoS Policy Applicability RxO Modiﬁable Type Matching
QoS matching
DURABILITY T, DR, DW Y N Data Availability QoS QoS QoS QoS QoS QoS QoS

DURABILITY SERVICE T, DW N N
Topic
Name

LIFESPAN T, DW - Y ... DataWriter writes Type reads DataReader
...

T, DR, DW N N ...
HISTORY
DomainParticipant DataWriter writes Type reads DataReader DomainParticipant
PRESENTATION P, S Y N Data Delivery Name
Topic
RELIABILITY T, DR, DW Y N
PARTITION P, S N Y QoS QoS QoS

DESTINATION ORDER T, DR, DW Y N

OWNERSHIP T, DR, DW Y N ‣ Rich set of QoS allow to configure
OWNERSHIP DW - Y
STRENGTH several different aspects of data
DEADLINE T, DR, DW Y Y Data Timeliness availability, delivery and timeliness
LATENCY BUDGET T, DR, DW Y Y

TRANSPORT PRIORITY T, DW - Y
‣ QoS can be used to control and
optimize network as well as
TIME BASED FILTER DR - Y Resources
computing resource
RESOURCE LIMITS T, DR, DW N N

USER_DATA DP, DR, DW N Y Conﬁguration
TOPIC_DATA T N Y
GROUP_DATA P, S N Y


Reliability
The reliability with which data is delivered to applications is impacted in DDS by the
following qualities of service
‣ RELIABILITY
‣ BEST_EFORT
‣ RELIABLE
‣ HISTORY
‣ KEEP_LAST (K)
‣ KEEP_ALL
‣ Theoretically, the only way to assure that an application will see all the samples
produced by a writer is to use RELIABLE+KEEP_ALL. Any other combination could
induce to samples being discarded on the receiving side because of the HISTORY depth


Real-Time
The real-time properties with which data is delivered to applications is impacted in DDS by the
following qualities of service:
‣ TRANSPORT_PRIORITY
‣ LATENCY_BUDGET
‣ In addition, DDS provides means for detecting performance failure, e.g., Deadline miss, by means
of the DEADLINE QoS
‣ Given a periodic task-set {T} with periods Di (with Di < Di+1) and deadline equal to the period, than
QoS should be set as follows:
‣ Assign to each task Ti a TRANSPORT_PRIORITY Pi such that Pi > Pi+1
‣ Set for each task Ti a DEADLINE QoS of Di
‣ For maximizing throughput and minimizing resource usage set for each Ti a LATENCY_BUDGET
QoS between Di /2 and Di/3 (this is a rule of thumb, the upper bound is Di-(RTT/2))


Eventual Consistency & R/W Caches
DataReader

DataReader 1 1

2 1 DataWriter
1 1
3 1

2 1 1 2
Topic
DataReader 1 2 2 3
3 1
DataReader Cache 2 2 2 3 3 1
Topic
1 1
DataReader Cache 2 Topic
1
DDS DataWriter Cache
3 1

Topic
DataReader Cache

Under an Eventual Consistency Model, DDS guarantees that all matched
Reader Caches will eventually be identical of the respective Writer Cache

QoS Impacting the Consistency Model
The DDS Consistency Model is a property that can be associated to Topics or further refined by
Reader/Writers. The property is controlled by the following QoS Policies:
‣ DURABILITY
‣ VOLATILE | TRANSIENT_LOCAL | TRANSIENT | PERSISTENT
‣ LIFESPAN

‣ RELIABILITY
‣ RELIABLE | BEST_EFFORT
‣ DESTINATION ORDER
‣ SOURCE_TIMESTAMP | DESTINATION_TIMESTAMP
QoS Policy Applicability RxO Modiﬁable
DURABILITY T, DR, DW Y N
LIFESPAN T, DW - Y
RELIABILITY T, DR, DW Y N
DESTINATION ORDER T, DR, DW Y N


QoS Impacting the Consistency Model

DURABILITY RELIABILITY DESTINATION_ORDER LIFESPAN
Eventual Consistency VOLATILE RELIABLE SOURCE_TIMESTAMP INF.
(No Crash / Recovery)
Eventual Consistency TRANSIENT_LOCAL RELIABLE SOURCE_TIMESTAMP INF.

(Reader Crash / Recovery)
Eventual Consistency TRANSIENT RELIABLE SOURCE_TIMESTAMP INF.
(Crash/Recovery)
Eventual Consistency PERSISTENT RELIABLE SOURCE_TIMESTAMP INF.
(Crash/Recovery)
Weak Consistency ANY ANY DESTINATION_TIMESTAMP ANY
Weak Consistency ANY BEST_EFFORT ANY ANY
Weak Consistency ANY ANY ANY N


Eventual Consistency @ Work
Eventual Consistency (Reader TRANSIENT_LOCAL RELIABLE SOURCE_TIMESTAMP INF.
Crash / Recovery)
{A}
{B}
(Crash/Recovery)
Weak Consistency ANY ANY ANY N {J}

S = {A, D}

S1
P = {A, B} B

P1 m

A F

J
D C
P = {D, C, J}

P2 K
E

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
P = {A, B} B

P1 m

A A F

J
D C
P = {D, C, J}

P2 K
E

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
P = {A, B} B
A
P1 m

B A
A F

J
D C
P = {D, C, J}

P2 K
E

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
P = {A, B} B
B
A
P1 m

A
A F

J
D C
P = {D, C, J}

P2 K
E

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
P = {A, B} B
B
A
P1 m
S= {A, B, J}
A
A F

S2
J
D C
P = {D, C, J}

P2 K
E

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
P = {A, B} B
B
A
P1 m
S= {A, B, J}
A
A F

S2
J
D C BA
P = {D, C, J}

P2 K
E

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
B
B
A
m
S= {A, B, J}
A F

S2
J
D C BA
P = {D, C, J}

P2 K
E

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
B
B
A
m
S= {A, B, J}
A F

S2
J
D C BA
P = {D, C, J} S= {A, B, D, J}

P2 K
E S3

S = {A}

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
B
B
A
m
S= {A, B, J}
A F

S2
J
J
D
D C BA
P = {D, C, J} S= {A, B, D, J}

P2 K
E S3

S = {A} JB

S4

Crash / Recovery)
{A}
{B}
(Crash/Recovery)

S = {A, D}

S1
B
B
A
m
S= {A, B, J}
A F

S2
J
D
D C BA
P = {D, C, J} S= {A, B, D, J}

P2 K
E S3

S = {A} JB

S4

Design Guidelines
‣ For all (non-periodic) Topics for which an eventually consistent model is required use the
following QoS settings:


(Crash / Recovery)

‣ For information produced periodically, with a period P, where P is small enough to be
acceptable as a consistency convergence delay, the following QoS settings will provide an
approximation of the eventual consistency:

Eventual Consistency VOLATILE BEST_EFFORT SOURCE_TIMESTAMP INF.
(Crash / Recovery)


OpenSplice DDS

OpenSplice DDS
Architecture

OpenSplice DDS Architectural Outlook

Architectural Highlights
‣ Shared-Memory based
architecture for minimizing
intra-nodal latency, as well as
maximizing nodal scalability
‣ Plugglable Service Architecture
‣ Full control over network
scheduling


Real-Time Networking Technology
Architecture
‣ Network-channels
Shared Single Copy per Node Shared
‣ Priority bands Pack Across Topics/Applications
‣ Network-partitions Memory Optimal Unmarshaling Memory
‣ Multicast Groups
‣ Traffic-shaping
‣ Burst/Throughput
OpenSplice DDS OpenSplice DDS
Binding Binding
Scalability and Efficiency Fault-Tolerance Pre-emptive Network Scheduler
‣ Single shared library for applications ‣ Active Channels Networking Priority Scheduler
Networking
Data Urgency Trafﬁc Pacing
& services ‣ Fall back on next
‣ Ring-fenced shared memory segment highest priority active
Network Channels
channel
‣ Data urgency driven network-packing Priority Bands

Determinism & Safety Trafﬁc Shaping
‣ Preemptive network-scheduler
‣ Data importance based network-channel selection
‣ Partition based multicast-group selection
‣ Managed critical network-resource


Durable Data Technology
Shared Memory Shared Memory
Architecture
‣ Fault-Tolerant Data
Availability Disk Disk

‣ Transient -- on memory OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS
Binding Binding Binding Binding
‣ Persistent -- on disk
Networking Durability Durability Networking
‣ Partitioning Persist Partitions
Persistent Data on Local Disk
‣ DDS Partitions Transient Data in Memory

‣ Alignment Dedicated Persistence Service Alignment Channel
‣ Dedicated Channels

Goal Features
‣ Transient QoS. Keep state-data outside the ‣ Fault-tolerant availability of non-volatile data
scope/lifecycle of its publishers ‣ Efficient delivery of initial data to late-joining applications
‣ Persistence QoS. Keep persistent settings to ‣ Pluggable Durability Service
outlive the system downtime
‣ Automatic alignment of replicated durability-services


OpenSplice DDS

Playing with
OpenSplice DDS

Online Resources

http://www.opensplice.com/
http://www.slideshare.net/angelo.corsaro
emailto:opensplicedds@prismtech.com

http://bit.ly/1Sreg http://twitter.com/acorsaro/

http://opensplice.blogspot.com
http://www.youtube.com/OpenSpliceTube


Getting Started with OpenSplice DDS Community Ed.

More Related Content

What's hot

Viewers also liked

Similar to Getting Started with OpenSplice DDS Community Ed.

More from Angelo Corsaro

Recently uploaded

Getting Started with OpenSplice DDS Community Ed.