DDS QoS Unleashed

Splice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS OpenSplice DDS

DDS QoS Unleashed
:: http://www.opensplice.org :: http://www.opensplice.com :: http://www.prismtech.com ::

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

Splice 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 DD
Agenda

‣ Recap of DDS Basics
‣ QoS Model
‣ DDS QoS
‣ QoS Patterns

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.

The OMG Data Distribution Service

DDS v1.2 API Standard Application

‣ Language Independent, OS and Object/Relational Mapping

HW architecture independent Data Local Reconstruction Layer (DLRL)

Content
‣ DCPS. Standard API for Data-
Ownership Durability
Subscription

Centric, Topic-Based, Real-Time Minimum Proﬁle

Publish/Subscribe
Data Centric Publish/Subscribe (DCPS)

Real-Time Publish/Subscribe Protocol

‣ DLRL. Standard API for creating DDS Interoperability Wire Protocol

Object Views out of collection of UDP/IP

Topics

The OMG Data Distribution Service

DDSI/RTPS v2.1 Wire Protocol Application
Standard Object/Relational Mapping

‣ Standard wire protocol allowing Data Local Reconstruction Layer (DLRL)

interoperability between different Ownership Durability
Content
Subscription
implementations of the DDS Minimum Proﬁle

standard Data Centric Publish/Subscribe (DCPS)

‣ Interoperability demonstrated Real-Time Publish/Subscribe Protocol

among key DDS vendors in March
DDS Interoperability Wire Protocol

2009
UDP/IP

OpenSplice DDS
Delivering Performance, Openness, and Freedom


How Does it
Works?!?

How Does it Work?
as a
c an be seen
Note: DDS NDA
n of the LI
relaxatio
odel
coord ination m

‣ DDS is based around the Brokers
concept of a fully distributed
Global Data Space (GDS)
DDS
‣ Applications can autonomously Global Data Space
and asynchronously read/
written data in the GDS

How Does it Work?

Brokers

‣ Publishers and
Subscribers can
DDS
join and leave the
Publisher
GDS at any time Global Data Space

How Does it Work?

Publisher Brokers Subscriber

‣ Publishers and
Subscribers can
DDS
join and leave the Subscriber
Publisher
GDS at any time Global Data Space

Publisher Subscriber

How Does it Work?

‣ Publishers and Publisher Brokers Subscriber

Subscribers express
their intent to
DDS
produce/consume Publisher
Subscriber

specific type of data, Global Data Space

e.g., Topics

How Does it Work?

‣ Subscriptions are
matched by taking
into account topics DDS Subscriber
(name, data type and Publisher Global Data Space
QoS)


How Does it Work?


‣ Subscriptions are
dynamically matched DDS
and Data flows from Publisher
Subscriber
Global Data Space
Publisher to
Subscribers

OpenSplice DDS


Defining Data

Topic -- the unit of information

Topic: Track, UFO, AirCraft, ...

‣ Unit of information
exchanged between Name

Publisher and Subscribers.

‣ An association between a Type Topic QoS

unique name, a type and a
{
QoS setting TrackedObject
Reliability
Deadline,
Priority
Transient,
...
}

Topic -- the unit of information

struct TrackedObject {
Topic Type: long oId;
‣ Type describing the data long x;
long y;
associated with one or more long size;
Topics };
#pragma keylist TrackedObject oId
‣ A Topic type can have a key
struct FlightPlan {
represented by an arbitrary string code;
number of attributes long trackId;
string origin;
string dest;
‣ Expressed in IDL (or XML) sequence<Coord> trajectory;
};
#pragma keylist FlightPlan code

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
struct TrackedObject {
long oId;
long x;
long y;
long size;
};
Topic Samples #pragma keylist TrackedObject oId

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

Topic/Instances/Samples Recap.

Topics Instances
UFO

FlyingCar
Airfraft
Samples

ti tj tnow time

Content Filtering
X0 X0 <= X <= X1 X1

‣ DDS allows the use of a subset of
SQL92 to specify content-filtered
Topics
Y0
‣ Content filters can be applied on
the entire content of the Topic Y0 <= Y <= Y1
Type

‣ Content filters are applied by DDS Y1
each time a new sample is
produced/delivered
(x BETWEEN (RANGE x0 AND x1))
AND
(y BETWEEN (RANGE y0 AND y1))

OpenSplice DDS


Quality of Service

QoS Model

‣ QoS-Policies provide Type Matching
QoS matching

control over local and QoS QoS QoS QoS QoS QoS QoS

end-to-end properties of Topic
Name

DDS entities

... DataWriter writes Type reads DataReader
...
...

‣ Local properties DomainParticipant DataWriter writes Type reads DataReader DomainParticipant

controlled by QoS are
Name
Topic

related resource usage QoS QoS QoS

‣ 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


QoS Policy Applicability RxO Modifiable
DURABILITY T, DR, DW Y N
QoS Policy Applicability RxO Modifiable
DURABILITY T, DW N N
SERVICE Data TIME BASED DR N/A Y
Availability FILTER
LIFESPAN T, DW N/A Y Resources
RESOURCE T, DR, DW N N
HISTORY T, DR, DW N N LIMITS
PRESENTATIO P, S Y N
ENTITY
N
FACTORY
RELIABILITY T, DR, DW Y N
USER DATA DP, DR, DW N Y Configuratio
PARTITION P, S N Y
Data TOPIC DATA T N Y n
DESTINATION T, DR, DW Y N
Delivery GROUP DATA P, S N Y
ORDER
LIVELINESS T, DR, DW Y N
OWNERSHIP T, DR, DW Y N
WRITER DATA DW N/A Y
OWNERSHIP DW N/A Y
LIFECYCLE
STRENGTH Lifecycle
READER DATA DR N/A Y
DEADLINE T, DR, DW Y Y
LIFECYCLE
LATENCY T, DR, DW Y Y
Data
BUDGET
Timeliness
TRANSPORT T, DW N/A Y
PRIORITY


Which properties does QoS controls?

TimeBasedFilter Deadline History

Data Data
Throughput Lifespan Durability
Latency Availability

Ownership
LatencyBudget TransportPriority Ownership
Strength

Control over Latency/Throughput tradeoff Control over data queueing
Control over data latency Control over data persistency
Control over data priority Control over data sources hot-swap

Reliability

Destination
Presentation Data Delivery
Order

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


Which properties does QoS controls?

TimeBasedFilter Deadline History

Data Data
Throughput Lifespan Durability
Latency Availability

Ownership
LatencyBudget TransportPriority Ownership
Strength

Control over Latency/Throughput tradeoff Control over data queueing
Control over data latency Control over data persistency
Control over data priority Control over data sources hot-swap

Reliability

Destination DDS provides programmatic QoS-driven
Presentation Data Delivery
Order support for configuring the most important
Control over data distribution reliability
properties of data distribution!
Control over data ordering
Control over presentation

Design by Contract in DDS

class ACCOUNT create
make
‣ Design by contract was popularized feature
balance: INTEGER
by Bertrand Meyer as a way of owner: PERSON
making explicit the pre/post minimum_balance: INTEGER is 1000

condition and invariants associated deposit (sum: INTEGER) is
with methods and the state of a -- Deposit sum into the account.
require
class do
sum >= 0

add(sum)
‣ DDS QoS allows to extend design by ensure
balance = old balance + sum
contract to non-functional aspects of end
an application --- Other methods
invariant
balance >= minimum_balance
end -- class ACCOUNT


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


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


DURABILITY
LIVELINESS
HISTORY
OWENERSHIP
LIFESPAN
OWN. STRENGTH

DEST. ORDER
DEADLINE
PARTITION
LATENCY BUDGET
PRESENTATION
TRANSPORT PRIO
RELIABILITY

TIME-BASED FILTER
USER DATA
RESOURCE LIMITS
TOPIC DATA
GROUP DATA
DW LIFECYCLE

DR LIFECYCLE

ENTITY FACTORY

RxO QoS Local QoS


DURABILITY
LIVELINESS
HISTORY
OWENERSHIP
LIFESPAN
OWN. STRENGTH

DEST. ORDER
DEADLINE
PARTITION
LATENCY BUDGET
PRESENTATION Topic
TRANSPORT PRIO
RELIABILITY

TIME-BASED FILTER
USER DATA
RESOURCE LIMITS
TOPIC DATA
GROUP DATA
DW LIFECYCLE

DR LIFECYCLE

ENTITY FACTORY

RxO QoS Local QoS Not Applicable


DURABILITY
LIVELINESS
HISTORY
OWENERSHIP
LIFESPAN
OWN. STRENGTH

DEST. ORDER
DEADLINE
PARTITION
LATENCY BUDGET
PRESENTATION DataWriter
TRANSPORT PRIO
RELIABILITY

TIME-BASED FILTER
USER DATA
RESOURCE LIMITS
TOPIC DATA
GROUP DATA
DW LIFECYCLE

DR LIFECYCLE

ENTITY FACTORY



DURABILITY
LIVELINESS
HISTORY
OWENERSHIP
LIFESPAN
OWN. STRENGTH

DEST. ORDER
DEADLINE
PARTITION
LATENCY BUDGET
PRESENTATION DataReader
TRANSPORT PRIO
RELIABILITY

TIME-BASED FILTER
USER DATA
RESOURCE LIMITS
TOPIC DATA
GROUP DATA
DW LIFECYCLE

DR LIFECYCLE

ENTITY FACTORY



DURABILITY
LIVELINESS
HISTORY
OWENERSHIP
LIFESPAN
OWN. STRENGTH

DEST. ORDER
DEADLINE
PARTITION
LATENCY BUDGET
PRESENTATION Publisher
TRANSPORT PRIO
RELIABILITY

TIME-BASED FILTER
USER DATA
RESOURCE LIMITS
TOPIC DATA
GROUP DATA
DW LIFECYCLE

DR LIFECYCLE

ENTITY FACTORY



DURABILITY
LIVELINESS
HISTORY
OWENERSHIP
LIFESPAN
OWN. STRENGTH

DEST. ORDER
DEADLINE
PARTITION
LATENCY BUDGET
PRESENTATION Subscriber
TRANSPORT PRIO
RELIABILITY

TIME-BASED FILTER
USER DATA
RESOURCE LIMITS
TOPIC DATA
GROUP DATA
DW LIFECYCLE

DR LIFECYCLE

ENTITY FACTORY



DURABILITY
LIVELINESS
HISTORY
OWENERSHIP
LIFESPAN
OWN. STRENGTH

DEST. ORDER
DEADLINE
PARTITION
Domain LATENCY BUDGET
PRESENTATION
Participant TRANSPORT PRIO
RELIABILITY

TIME-BASED FILTER
USER DATA
RESOURCE LIMITS
TOPIC DATA

GROUP DATA
DW LIFECYCLE

DR LIFECYCLE

ENTITY FACTORY


OpenSplice DDS


Organizing Data

Partitions QoS

‣ The Partition QoS Policy QoS Domain Applicability
Policy RxO Modiﬁable
can be used as subjects PARTITION P, S N Y

organizing the flow of data
‣ The Partition QoS Policy is Subscriber

used to connect
Publisher "tracks.kfo" "tracks.ufo"

Publishers/Subscribers to a
Partitions’ List which might
also contain wildcards, e.g. Publisher
Subscriber
tracks.*
‣ Topics are published and
subscribed across one or Publisher Subscriber
more Partitions Partition

OpenSplice DDS


Example


DataReader
<TrakedObject>
DataWriter Subscriber
<TrakedObject> "airspace.kfo.aircrafts" DataReader
<TrakedObject>
Publisher
DataWriter AirCraft FlightPlan
<FlightPlan> DataReader
Subscriber <FlightPlan>

"airspace.tfo"
DataWriter
<FlightPlan> Publisher Tracks
Subscriber
DataReader
<Tracks>

"airspace.kfo.flyingcars"
DataReader
DataWriter <TrackedObject>
<TrakedObject> Subscriber
Publisher FlyingCar FlightPlan
DataWriter DataReader
<FlightPlan> <FlightPlan>

Partition Global Data Space (GDS)

Topic


DataReader
<TrakedObject>
<TrakedObject>
Publisher

"airspace.tfo"
DataWriter
Subscriber
DataReader
<Tracks>

DataReader

“airspace.*”

Topic


DataReader
<TrakedObject>
<TrakedObject>
Publisher

"airspace.tfo"
DataWriter
Subscriber
DataReader
<Tracks>

DataReader

“airspace.kfo.*”

Topic

OpenSplice DDS


Controlling
Reliability

Reliability QoS

QoS Policy Applicability RxO Modifiable

QoS matching

The RELIABILITY QoS indicate the QoS QoS QoS

level of guarantee offered by the QoS Topic QoS
Name

DDS in delivering data to DataWriter writes Type reads DataReader

subscribers.
Publisher ... Subscriber
... ...

DataWriter writes Type reads DataReader

Name
Topic

QoS QoS QoS

QoS matching

Reliability QoS


Possible variants are: RELIABILITY T, DR, DW Y N

‣ Reliable. In steady-state the QoS matching

middleware guarantees that all
QoS QoS QoS

samples in the DataWriter QoS Topic
Name
QoS

history will eventually be Publisher

Subscriber
...
delivered to all the DataReader ... ...


‣ Best Effort. Indicates that it is
Name
Topic

acceptable to not retry QoS QoS QoS

propagation of any samples QoS matching

History QoS
How many data samples should I keep?



The HISTORY QoS policy HISTORY T, DR, DW N N

controls whether the DDS should QoS matching

deliver only the most recent
QoS QoS QoS

value, attempt to deliver all
QoS Topic QoS
Name

reads DataReader

intermediate values, or do
DataWriter writes Type

... ...

something in between. DataWriter writes Type reads DataReader

Name
Topic

QoS QoS QoS

QoS matching

History QoS
How many data samples should I keep?


The policy can be configured to provide

DataReader
1 1

the following semantics: 2 1

3 1

‣ Keep Last. The DDS will only History Depth = 1 (DDS Default)

attempt to keep the most recent
“depth” samples of each instance
of data identified by its key

DataReader
1 1 1 2 1 3 1 4 1 5

‣ Keep All. The DDS will attempt 2 1 2 2 2 3 2 4 2 5

to keep all the samples of each 3 1 3 2 3 3 3 4 3 5

instance of data identified by its
History Depth = 5

key.

OpenSplice DDS


Topic Used in next section.
struct Counter {
int cID; History in
int count;
};
#pragma keylist Counter cID Action


History Depth = 1 History Depth = 1
(DDS Default) (DDS Default)
Network
1 1 1 2

DataReader 2 1 1 2 2 3
DataWriter
3 1 2 2 2 3 3 1

Topic Topic

DataReader Cache DataWriter Cache


Network
1 2 1 2

DataReader 2 2 2 3
DataWriter
3 1 2 3 3 1

Topic Topic


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


Network
1 2 1 2

DataReader 2 3 2 3
DataWriter
3 1 3 1

Topic Topic




History = Keep All History Depth = 1
(DDS Default)
Network
DataReader

1 1 1 2

2 1 1 2 2 3
DataWriter
3 1 2 2 2 3 3 1

Topic Topic




(DDS Default)
Network
DataReader

1 1 1 2 1 2

2 1 2 2 2 3
DataWriter
3 1 2 3 3 1

Topic Topic




(DDS Default)
Network
DataReader

1 1 1 2 1 2

2 1 2 2 2 3 2 3
DataWriter
3 1 3 1

Topic Topic



Putting it All Together

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

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

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

Tracks and Flight Plans

Track FlightPlan

Name Name

Type Topic QoS Type Topic QoS

{ TrackedObject {
TrackedObject BEST_EFFORT RELIABLE
KEEP_LAST(1) KEEP_LAST(1)
RESOURCE_LIMITS RESOURCE_LIMITS
} }

Aerospace Violations

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

Type Topic QoS

ASViolation {
RELIABLE
KEEP_ALL
RESOURCE_LIMITS
}

OpenSplice DDS


Controlling
Real-Time Properties

Deadline QoS
You can’t be later than...


DEADLINE T, DR, DW Y Y

QoS matching

The DEADLINE QoS policy allows
QoS QoS QoS

QoS Topic QoS

to define the maximum inter-
Name


arrival time between data
... ...

samples

Name
Topic

QoS QoS QoS

QoS matching

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

Deadline Deadline Deadline Deadline Deadline

Deadline Violation

Latency Budget QoS
I need to get there in at most...


LATENCY T, DR, DW Y Y

The LATENCY_BUDGET QoS policy
BUDGET

specifies the maximum acceptable QoS matching

delay from the time the data is QoS QoS QoS

written until the data is inserted in the
QoS Topic QoS
Name


receiver's application-cache Publisher ... ... ... Subscriber


Name
Topic

QoS QoS QoS

QoS matching

Latency Budget QoS

‣ The default value of the
duration is zero indicating
that the delay should be
minimized
TBuff Latency Budget = Latency = TBuff +T1+T2+T3

‣ This policy is a hint to the
T3
T1

DDS, not something that T2

must be monitored or
enforced.

Transport Priority QoS
VIP Data, stay clear!


TRANSPORT T, DW - Y
PRIORITY

The TRANSPORT_PRIORITY
QoS policy is a hint to the QoS matching

infrastructure as to how to
QoS QoS QoS

set the priority of the
QoS Topic QoS
Name


underlying transport used to Publisher ... ... ... Subscriber

send the data. DataWriter writes Type reads

Name
DataReader

Topic

QoS QoS QoS

QoS matching

Putting it all Together QoS

The real-time properties with which data is delivered to applications is impacted in DDS by the
following qualities of service:
‣ TRANSPORT_PRIORITY Deadline Deadline Deadline Deadline Deadline

‣ LATENCY_BUDGET
Deadline Violation
‣ 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))

Tracks and Flight Plans

Track FlightPlan

Name Name

Type Topic QoS Type Topic QoS

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

Aerospace Violations

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

Type Topic QoS

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

OpenSplice DDS


Controlling the
Consistency Model

Durability QoS

The DURABILITY QoS controls the data availability w.r.t. late joiners, specifically
the DDS provides the following variants:
‣ Volatile. No need to keep data DURABILITY T, DW N N

instances for late joining data readers SERVICE

‣ Transient Local. Data instance QoS matching

availability for late joining data reader is
QoS QoS QoS

tied to the data writer availability QoS Topic
Name
QoS


‣ Transient. Data instance availability
... ...

outlives the data writer DataWriter writes Type reads DataReader

Name
Topic

‣ Persistent. Data instance availability QoS QoS QoS

outlives system restarts QoS matching

Eventual Consistency & R/W Caches

Under an Eventual Consistency Model, DDS guarantees
DataReader that all matched Reader Caches will eventually be
identical of the respective Writer Cache
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

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 QoS Policy Applicability RxO Modiﬁable

‣ RELIABILITY LIFESPAN T, DW - Y
‣ RELIABLE | BEST_EFFORT DESTINATION ORDER T, DR, DW Y N

‣ DESTINATION ORDER
‣ SOURCE_TIMESTAMP | DESTINATION_TIMESTAMP

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


DURABILITY RELIABILITY DESTINATION_ORDER LIFESPAN
Eventual Consistency (Reader TRANSIENT_LOCAL RELIABLE SOURCE_TIMESTAMP INF.
Crash / Recovery)
{A}
Eventual Consistency TRANSIENT RELIABLE SOURCE_TIMESTAMP INF.
{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

DDS QoS Unleashed

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Andere mochten auch

Andere mochten auch (20)

Ähnlich wie DDS QoS Unleashed

Ähnlich wie DDS QoS Unleashed (20)

Mehr von Angelo Corsaro

Mehr von Angelo Corsaro (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

DDS QoS Unleashed