dds qos unleashed

Angelo Corsaro, Ph.D.Chief Technology Officer

PrismTechOMG DDS SIG Co-Chair

[email protected]

:: http://www.opensplice.org :: http://www.opensplice.com :: http://www.prismtech.com ::

OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS

OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS

DDS QoS Unleashed

mailto:[email protected]


http://www.prismtech.com/opensplice-dds


http://www.prismtech.com




http://www.opensplice.com




http://www.opensplice.org


Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Agenda

‣ Recap of DDS Basics‣QoS Model

‣ DDS QoS

‣QoS Patterns





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


The OMG DDS

The OMG DDS Standard‣ Introduced in 2004 to address the Data

distribution challenges typical of Defense and Aerospace Applications

‣ Key requirement for the standard were high performance and scalability from embedded to ultra-large-scale deployments

‣ Today recommended by key administration worldwide and widely adopted well beyond Aerospace and Defense in domains, such as, Automated Trading, Simulations, SCADA, Telemetry, etc.





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


The OMG Data Distribution Service

DDS v1.2 API Standard

‣ Language Independent, OS and HW architecture independent

‣ DCPS. Standard API for Data-Centric, Topic-Based, Real-Time Publish/Subscribe

‣ DLRL. Standard API for creating Object Views out of collection of Topics

Object/Relational Mapping

Ownership DurabilityContent

Subscription

Minimum Profile

Data Centric Publish/Subscribe (DCPS)

Data Local Reconstruction Layer (DLRL)

DDS Interoperability Wire Protocol

Application

UDP/IP

Real-Time Publish/Subscribe Protocol















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


The OMG Data Distribution Service

DDSI/RTPS v2.1 Wire Protocol Standard

‣ Standard wire protocol allowing interoperability between different implementations of the DDS standard

‣ Interoperability demonstrated among key DDS vendors in March 2009

Object/Relational Mapping

Ownership DurabilityContent

Subscription

Minimum Profile

Data Centric Publish/Subscribe (DCPS)

Data Local Reconstruction Layer (DLRL)

DDS Interoperability Wire Protocol

Application

UDP/IP

Real-Time Publish/Subscribe Protocol












D e l i v e r i n g P e r f o r m a n c e , O p e n n e s s , a n d F r e e d o m

OpenSplice DDS:: http://www.opensplice.org :: http://www.opensplice.com :: http://www.prismtech.com ::

How Does it Works?!?













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


How Does it Work?

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

‣ Applications can autonomously and asynchronously read/written data in the GDS

Brokers

Note: DDS can be seen as a

relaxation of the LINDA

coordination model

DDSGlobal Data Space





















Brokers

Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


How Does it Work?

‣ Publishers and Subscribers can join and leave the GDS at any time

Publisher




















Brokers

Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


How Does it Work?

‣ Publishers and Subscribers can join and leave the GDS at any time

Subscriber

Subscriber

Subscriber

Publisher

Publisher

Publisher




















Brokers Subscriber

Subscriber

Subscriber

Publisher

Publisher

Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


How Does it Work?

‣ Publishers and Subscribers express their intent to produce/consume specific type of data, e.g., Topics

Publisher




















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


How Does it Work?

‣ Subscriptions are matched by taking into account topics (name, data type and QoS)

Brokers Subscriber

Subscriber

Subscriber

Publisher

Publisher

Publisher




















Brokers

Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


How Does it Work?

‣ Subscriptions are dynamically matched and Data flows from Publisher to Subscribers

Subscriber

Subscriber

Subscriber

Publisher

Publisher

Publisher
























Defining Data













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Topic -- the unit of information

Topic:

‣ Unit of information exchanged between Publisher and Subscribers.

‣ An association between a unique name, a type and a QoS setting TrackedObject

Track, UFO, AirCraft, ...

{ Reliability Deadline, Priority Transient, ...}

TopicType QoS

Name





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Topic -- the unit of information

Topic Type:

‣ Type describing the data associated with one or more Topics

‣ A Topic type can have a key represented by an arbitrary number of attributes

‣ Expressed in IDL (or XML)

struct TrackedObject { long oId; long x; long y; long size;};#pragma keylist TrackedObject oId

struct FlightPlan { string code; long trackId; string origin; string dest; sequence<Coord> trajectory;};#pragma keylist FlightPlan code





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


DDS Topic Instances and Samples

Topic Samples

‣ The values assumed by a Topic Instance over time are referred as Instance Sample

Topic Instances

‣ Each key value identifies a unique Topic Instance

‣ Topic’s instance lifetime can be explicitly managed in DDS

struct TrackedObject { long oId; long x; long y; long size;};#pragma keylist TrackedObject oId













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Topic/Instances/Samples Recap.

Topics Instances

Samples

timeti tj tnow

UFO

AirfraftFlyingCar




















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Content Filtering

‣ DDS allows the use of a subset of SQL92 to specify content-filtered Topics

‣ Content filters can be applied on the entire content of the Topic Type

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

X0 X1

Y0

Y1

X0 <= X <= X1

Y0 <= Y <= Y1

(x BETWEEN (RANGE x0 AND x1)) AND(y BETWEEN (RANGE y0 AND y1))
























Quality of Service













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


QoS Model

‣ End-to-end properties controlled by QoS are related to temporal and spatial aspects of data distribution

‣ Some QoS-Policies are matched based on a Request vs. Offered Model thus QoS-enforcement

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

......

QoS QoS

Type Matching

DomainParticipant DomainParticipant

QoS QoS

‣ QoS-Policies provide control over local and end-to-end properties of DDS entities

‣ Local properties controlled by QoS are related resource usage






















QoS Policy Applicability RxO ModifiableDURABILITY

DURABILITY SERVICE

LIFESPAN

HISTORY

PRESENTATION

RELIABILITY

PARTITION

DESTINATION ORDER

OWNERSHIP

OWNERSHIP STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIORITY

T, DR, DW Y N

Data Availability

T, DW N NData

AvailabilityT, DW N/A Y

Data Availability

T, DR, DW N N

Data Availability

P, S Y N

Data Delivery

T, DR, DW Y N

Data Delivery

P, S N YData

DeliveryT, DR, DW Y NData

Delivery

T, DR, DW Y N

Data Delivery

DW N/A Y

Data Delivery

T, DR, DW Y Y

Data Timeliness

T, DR, DW Y YData

TimelinessT, DW N/A Y

Data Timeliness

TIME BASED FILTER

RESOURCE LIMITS

ENTITY FACTORY

USER DATA

TOPIC DATA

GROUP DATA

LIVELINESS

WRITER DATA LIFECYCLE

READER DATA LIFECYCLE

DR N/A Y

ResourcesT, DR, DW N N

Resources

Configuration

DP, DR, DW N Y ConfigurationT N Y

Configuration

P, S N Y

Configuration

T, DR, DW Y N

Configuration

DW N/A Y

LifecycleDR N/A Y

Lifecycle

QoS Policy Applicability RxO Modifiable














Data Latency

LatencyBudget TransportPriority

Throughput

DeadlineTimeBasedFilter

Control over Latency/Throughput tradeoff Control over data latency Control over data priority

Data Availability

OwnershipOwnershipStrength

Durability

History

Lifespan

Control over data queueing Control over data persistency Control over data sources hot-swap

Data Delivery

Reliability

DestinationOrder

Presentation

Control over data distribution reliability Control over data ordering Control over presentation

Which properties does QoS controls?














Data Latency

LatencyBudget TransportPriority

Throughput

DeadlineTimeBasedFilter

Control over Latency/Throughput tradeoff Control over data latency Control over data priority

Data Availability

OwnershipOwnershipStrength

Durability

History

Lifespan

Control over data queueing Control over data persistency Control over data sources hot-swap

Data Delivery

Reliability

DestinationOrder

Presentation

Control over data distribution reliability Control over data ordering Control over presentation

DDS provides programmatic QoS-driven support for configuring the most important properties of data distribution!

Which properties does QoS controls?













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Design by Contract in DDS

‣ Design by contract was popularized by Bertrand Meyer as a way of making explicit the pre/post condition and invariants associated with methods and the state of a class

‣ DDS QoS allows to extend design by contract to non-functional aspects of an application

class ACCOUNT create makefeature balance: INTEGER owner: PERSON minimum_balance: INTEGER is 1000

deposit (sum: INTEGER) is -- Deposit sum into the account. require sum >= 0 do add(sum) ensure balance = old balance + sum end--- Other methodsinvariant balance >= minimum_balanceend -- class ACCOUNT





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S



Capturing System Invariants‣ The weakest precondition, meaning the weakest QoS, required

by the system to properly perform should be captured as QoS attached to the information model, e.g. Topics.

Refining Invariants‣ QoS associated with the information model, should be only

strengthened by overriding QoS at a DataWriter level ‣ QoS should never be weakened by overriding it at a

DataReader level





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S



QoS Contract Enforcements‣ The RxO model ensures that unless QoS are matched no

actual subscription will be established

‣ This ensure that only if QoS contracts are satisfied communication will be established






















ENTITY FACTORY

HISTORY

LIFESPAN

DURABILITY

OWENERSHIP

OWN. STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIO

TIME-BASED FILTER

RESOURCE LIMITSUSER DATA

TOPIC DATA

GROUP DATA

LIVELINESS

DW LIFECYCLE

DR LIFECYCLE

PRESENTATION

RELIABILITY

PARTITION

DEST. ORDER

RxO QoS Local QoS














ENTITY FACTORY

HISTORY

LIFESPAN

DURABILITY

OWENERSHIP

OWN. STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIO

TIME-BASED FILTER


TOPIC DATA

GROUP DATA

LIVELINESS

DW LIFECYCLE

DR LIFECYCLE

PRESENTATION

RELIABILITY

PARTITION

DEST. ORDER

Topic

RxO QoS Local QoS Not Applicable














ENTITY FACTORY

HISTORY

LIFESPAN

DURABILITY

OWENERSHIP

OWN. STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIO

TIME-BASED FILTER


TOPIC DATA

GROUP DATA

LIVELINESS

DW LIFECYCLE

DR LIFECYCLE

PRESENTATION

RELIABILITY

PARTITION

DEST. ORDER

DataWriter















ENTITY FACTORY

HISTORY

LIFESPAN

DURABILITY

OWENERSHIP

OWN. STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIO

TIME-BASED FILTER


TOPIC DATA

GROUP DATA

LIVELINESS

DW LIFECYCLE

DR LIFECYCLE

PRESENTATION

RELIABILITY

PARTITION

DEST. ORDER

DataReader















ENTITY FACTORY

HISTORY

LIFESPAN

DURABILITY

OWENERSHIP

OWN. STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIO

TIME-BASED FILTER


TOPIC DATA

GROUP DATA

LIVELINESS

DW LIFECYCLE

DR LIFECYCLE

PRESENTATION

RELIABILITY

PARTITION

DEST. ORDER

Publisher















HISTORY

LIFESPAN

DURABILITY

OWENERSHIP

OWN. STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIO

TIME-BASED FILTER


TOPIC DATA

GROUP DATA

LIVELINESS

DW LIFECYCLE

DR LIFECYCLE

PRESENTATION

RELIABILITY

PARTITION

DEST. ORDER

Subscriber

ENTITY FACTORY















HISTORY

LIFESPAN

DURABILITY

OWENERSHIP

OWN. STRENGTH

DEADLINE

LATENCY BUDGET

TRANSPORT PRIO

TIME-BASED FILTER


TOPIC DATA

GROUP DATA

LIVELINESS

DW LIFECYCLE

DR LIFECYCLE

PRESENTATION

RELIABILITY

PARTITION

DEST. ORDER

Domain Participant

ENTITY FACTORY
















Organizing Data













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Partitions QoS

‣ The Partition QoS Policy can be used as subjects organizing the flow of data

‣ The Partition QoS Policy is used to connect Publishers/Subscribers to a Partitions’ List which might also contain wildcards, e.g. tracks.*

‣ Topics are published and subscribed across one or more Partitions

Domain

Subscriber

Subscriber

Subscriber

"tracks.kfo" "tracks.ufo"

Publisher

Publisher

Publisher

Partition

PARTITION P, S N Y






















Example














"airspace.kfo.aircrafts"

"airspace.kfo.flyingcars"

"airspace.tfo"

TracksPublisher

Publisher

Publisher

Subscriber

Subscriber

Subscriber

DataWriter<TrakedObject>

DataWriter<FlightPlan>

DataReader<TrakedObject>





DataReader<Tracks>

Subscriber DataReader<FlightPlan>

DataReader<TrackedObject>

DataReader<FlightPlan>

Global Data Space (GDS)Partition

Topic

FlightPlanAirCraft

FlightPlanFlyingCar
















"airspace.tfo"

TracksPublisher

Publisher

Publisher

Subscriber

Subscriber

Subscriber








DataReader<Tracks>





Topic

FlightPlanAirCraft

FlightPlanFlyingCar

“airspace.*”
















"airspace.tfo"

TracksPublisher

Publisher

Publisher

Subscriber

Subscriber

Subscriber








DataReader<Tracks>





Topic

FlightPlanAirCraft

FlightPlanFlyingCar

“airspace.kfo.*”















Controlling Reliability













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Reliability QoS

The RELIABILITY QoS indicate the level of guarantee offered by the DDS in delivering data to subscribers.


RELIABILITY T, DR, DW Y N

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

QoS

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

QoS matching

......





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Reliability QoS

Possible variants are:QoS Policy Applicability RxO Modifiable

RELIABILITY T, DR, DW Y N

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

QoS

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

QoS matching

......

‣ Reliable. In steady-state the middleware guarantees that all samples in the DataWriter history will eventually be delivered to all the DataReader

‣ Best Effort. Indicates that it is acceptable to not retry propagation of any samples






















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


History QoS

The HISTORY QoS policy controls whether the DDS should deliver only the most recent value, attempt to deliver all intermediate values, or do something in between.


HISTORY T, DR, DW N N

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

QoS

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

QoS matching

......

How many data samples should I keep?





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


History QoS

The policy can be configured to provide the following semantics:

How many data samples should I keep?

‣ Keep Last. The DDS will only attempt to keep the most recent “depth” samples of each instance of data identified by its key

‣ Keep All. The DDS will attempt to keep all the samples of each instance of data identified by its key.

1 1

2 1

3 1

History Depth = 1 (DDS Default)

1 1

2 1

3 1

1 2 1 3 1 4 1 5

2 2 2 3 2 4 2 5

3 2 3 3 3 4 3 5

History Depth = 5

Dat

aRea

der

Dat

aRea

der























History in Action

struct Counter { int cID; int count;};#pragma keylist Counter cID

Topic Used in next section.














Topic

DataReader

1 1

2 1

3 1


DataReader Cache

Topic

1 2

2 3

3 1


DataWriter Cache

DataWriter1 2

2 2 2 3

Network














Topic

DataReader

1 2

2 2

3 1


DataReader Cache

Topic

1 2

2 3

3 1


DataWriter Cache

DataWriter2 3

Network

Note: The Reliability QoS controls wether data is sent reliably, or best-effort, from the DataWriter to matched DataReaders














Topic

DataReader

1 2

2 3

3 1


DataReader Cache

Topic

1 2

2 3

3 1


DataWriter Cache

DataWriter

Network















TopicDat

aRea

der

1 1

2 1

3 1

History = Keep All

DataReader Cache

Topic

1 2

2 3

3 1


DataWriter Cache

DataWriter1 2

2 2 2 3

Network















TopicDat

aRea

der

1 1

2 1

3 1

History = Keep All

DataReader Cache

Topic

1 2

2 3

3 1


DataWriter Cache

DataWriter

1 2

2 2

2 3

Network















TopicDat

aRea

der

1 1

2 1

3 1

History = Keep All

DataReader Cache

Topic

1 2

2 3

3 1


DataWriter Cache

DataWriter

1 2

2 2 2 3

Network














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

Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Putting it All Together





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Putting it All Together

‣ 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





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Reliability Gotchas

‣ The RESOURCE_LIMITS QoS should always be taken in to account when dealing with the reliable data distribution since it impacts the memory usage (and potentially the DW blocking probability)

‣ Three values have to be provided:

‣ max_samples_per_instance (>= history depth)‣ max_samples (>= max_samples_per_instance)‣ max_instances























Example













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Tracks and Flight Plans

TrackedObject

Track

{ BEST_EFFORT KEEP_LAST(1) RESOURCE_LIMITS}

TopicType QoS

Name

TrackedObject

FlightPlan

{ RELIABLE KEEP_LAST(1) RESOURCE_LIMITS}

TopicType QoS

Name





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Aerospace Violations

ASViolation

AerospaceViolation

{ RELIABLE KEEP_ALL RESOURCE_LIMITS}

TopicType QoS

Name

struct ASViolation { long oId; string sign; long vcode;};#pragma keylist ASViolation oId sign























Controlling Real-Time Properties













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Deadline QoS

The DEADLINE QoS policy allows to define the maximum inter-arrival time between data samples


DEADLINE T, DR, DW Y Y

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

QoS

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

QoS matching

......

You can’t be later than...





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Deadline QoS

‣ DataWriter indicates that the application commits to write a new value at least once every deadline period

‣ DataReaders are notified by the DDS when the DEADLINE QoS contract is violated

Publisher Subscriber

DeadlineDeadlineDeadlineDeadlineDeadline

Deadline Violation





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Latency Budget QoS

The LATENCY_BUDGET QoS policy specifies the maximum acceptable delay from the time the data is written until the data is inserted in the receiver's application-cache


LATENCY

BUDGET

T, DR, DW Y Y

I need to get there in at most...

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

QoS

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

QoS matching

......





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Latency Budget QoS

‣ The default value of the duration is zero indicating that the delay should be minimized

‣ This policy is a hint to the DDS, not something that must be monitored or enforced.

T1

T2

T3

Latency Budget = Latency = TBuff +T1+T2+T3TBuff





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Transport Priority QoS

The TRANSPORT_PRIORITY QoS policy is a hint to the infrastructure as to how to set the priority of the underlying transport used to send the data.


TRANSPORT

PRIORITY

T, DW - Y

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

QoS

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

QoS matching

......

VIP Data, stay clear!





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Putting it all Together QoSThe 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))

Publisher Subscriber

DeadlineDeadlineDeadlineDeadlineDeadline

Deadline Violation





Example













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S



TrackedObject

Track

{ BEST_EFFORT KEEP_LAST(1) RESOURCE_LIMITS DEADLINE (= Period) TRANSPORT_PRIORITY LATENCY_BUDGET (= Period/3)}

TopicType QoS

Name

TrackedObject

FlightPlan

{ RELIABLE KEEP_LAST(1) RESOURCE_LIMITS}

TopicType QoS

Name





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S



ASViolation

AerospaceViolation

{ RELIABLE KEEP_ALL RESOURCE_LIMITS LATENCY_BUDGET (=0) TRANSPORT_PRIORITY (= MAX_PRIO)}

TopicType QoS

Name
























Controlling the Consistency Model













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Durability QoS

‣Volatile. No need to keep data instances for late joining data readers

‣Transient Local. Data instance availability for late joining data reader is tied to the data writer availability

‣Transient. Data instance availability outlives the data writer

‣Persistent. Data instance availability outlives system restarts

Publisher

DataWriter

Topic

Type

QoS

Name

writes

QoS

QoS

DataWriter

Topic

Typewrites

Subscriber

DataReaderreads

QoS

DataReaderreads

...

QoS

Name

QoS

QoS QoS

QoS matching

QoS matching

......

The DURABILITY QoS controls the data availability w.r.t. late joiners, specifically the DDS provides the following variants:


DURABILITY

DURABILITY

SERVICE

T, DR, DW Y N

T, DW N N





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Eventual Consistency & R/W Caches

Under an Eventual Consistency Model, DDS guarantees that all matched Reader Caches will eventually be

identical of the respective Writer Cache

Topic

DataReader

1 1

2 1

3 1

DataReader Cache Topic

1 2

2 3

3 1

DataWriter Cache

DataWriter

1 2

2 2 2 3

Topic

1 1

2 1

3 1

DataReader Cache

Topic

DataReader

1 1

2 1

3 1

DataReader Cache

DDS

DataReader





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


QoS & 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


DURABILITY

LIFESPAN

RELIABILITY

DESTINATION ORDER

T, DR, DW Y N

T, DW - Y

T, DR, DW Y N

T, DR, DW Y N













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


QoS & Consistency Model

DURABILITY RELIABILITY DESTINATION_ORDER LIFESPAN

Eventual Consistency (No Crash / Recovery)

Eventual Consistency (Reader Crash / Recovery)

Eventual Consistency(Crash/Recovery)


Weak Consistency

Weak ConsistencyWeak Consistency

VOLATILE RELIABLE SOURCE_TIMESTAMP INF.

TRANSIENT_LOCAL RELIABLE SOURCE_TIMESTAMP INF.

TRANSIENT RELIABLE SOURCE_TIMESTAMP INF.

PERSISTENT RELIABLE SOURCE_TIMESTAMP INF.

ANY ANY DESTINATION_TIMESTAMP ANY

ANY BEST_EFFORT ANY ANY

ANY ANY ANY N






















A

B

CD

E

F

m

J

K

P1

P2

S1P = {A, B}

S = {A, D}

P = {D, C, J}

S4

S = {A}






{A}

{B}

Weak Consistency ANY ANY ANY N {J}














A

B

CD

E

F

m

J

K

A

P1

P2

S1P = {A, B}

S = {A, D}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

K

A

P1

P2

S1

A

P = {A, B}

S = {A, D}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















B A

B

CD

E

F

m

J

K

A

P1

P2

S1

A

P = {A, B}

S = {A, D}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

K

A

P1

P2

S1B

A

P = {A, B}

S = {A, D}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

K

A

P1

P2

S1

S2

B

A

B

A

P = {A, B}

S = {A, D}

S= {A, B, J}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

K

A

P1

P2

S1

S2

B

A

B

A

P = {A, B}

S = {A, D}

S= {A, B, J}

P = {D, C, J}B

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

KP2

S1

S2

A

BA

BB

S = {A, D}

S= {A, B, J}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

KP2

S1

S2

S3

A

BA

B

S= {A, B, D, J}

B

S = {A, D}

S= {A, B, J}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

KP2

S1

S2

S3

A

BA

B

S= {A, B, D, J}

J

B

D

J

S = {A, D}

S= {A, B, J}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}















A

B

CD

E

F

m

J

KP2

S1

S2

S3

A

BA

B

S= {A, B, D, J}

B

D

J

S = {A, D}

S= {A, B, J}

P = {D, C, J}

S4

S = {A}

A






{A}

{B}
















Example













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S



TrackedObject

Track

{ BEST_EFFORT KEEP_LAST(1) VOLATILE DEST_ORDER LIFESPAN (>= Period) }

TopicType QoS

Name

TrackedObject

FlightPlan

{ RELIABLE KEEP_LAST(1) TRANSIENT - or - PERSISTENT DEST_ORDER LIFESPAN (Inf)}

TopicType QoS

Name





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S



ASViolation

AerospaceViolation

{ RELIABLE KEEP_ALL PERSISTENT DEST_ORDER LIFESPAN (Inf)}

TopicType QoS

Name
























Controlling Replication













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Availability

Availability of data producers can be controlled via two QoS Policies

‣ OWNERSHIP (SHARED vs. EXCLUSIVE)

‣ OWNERSHIP STRENGTH

‣ Instances of exclusively owned Topics can be modified (are owned) by the higher strength writer

‣ Writer strength is used to coordinate replicated writers





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Availability

R1

R2

R3

symbol: "MSFT"name: "Microsoft Corp."exchange: "NASD"quote: 33.73

StockQuote

symbol: "GOOG"name: "Google Inc."exchange: "NASD"quote: 663.97

StockQuote

W1

W2’’

STRENGTH=3

STRENGTH=1


StockQuote


StockQuotesymbol: "AAPL"name: "Apple Inc."exchange: "NASD"quote: 165.37

StockQuote

W1’

STRENGTH=2


StockQuote



StockQuote


StockQuote


StockQuote

symbol: "AAPL"name: "Apple Inc."exchange: "NASD"quote: 165.37


StockQuote


StockQuote





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Availability

R1

R2

R3


StockQuote


StockQuote

W1

W2’’

STRENGTH=3

STRENGTH=1


StockQuote


StockQuote

W1’

STRENGTH=2


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Availability

R1

R2

R3


StockQuote


StockQuote

W1

W2’’

STRENGTH=3

STRENGTH=1


StockQuote

W1’

STRENGTH=2


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Availability


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote

R1

R2

R3W2’’

STRENGTH=1





















Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Availability


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuote


StockQuoteR1

R2

R3W2’’

STRENGTH=1























Summing Up +/-













Ope

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

SOpe

nSpl

ice

DD

S


Summing Up

‣ DDS makes it possible for you to express the non-functional contract for your distributed applications

‣ DDS QoS Policies give you control over local and end-to-end properties

‣ In summary QoS Policies and Data Centricity gives you the ability to apply Design by Contract at a functional and non-functional level





















http://www.opensplice.com/

http://www.opensplice.org/

emailto:[email protected]

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

http://bit.ly/1Sreg

http://www.slideshare.net/angelo.corsaro

http://twitter.com/acorsaro/


OpenSplice DDSReferences











http://bit.ly/1Sreg

http://bit.ly/1Sreg






DownLoad OpenSplice DDS at


THANK You!P.S. Enjoyed the talk? Found it

Bloody boring? Send me your

comments at:

[email protected]

The Universal Data BusOpenSplice DDS

















































mailto:[email protected]?subject=Tweeting%20with%20OpenSplice%20Feedback





















