dds in action part ii

72
Angelo Corsaro, PhD Chief Technology Officer ADLINK Technologies Inc. [email protected] DDS in Action Part-II

Upload: angelo-corsaro

Post on 22-Jan-2018

630 views

Category:

Technology


2 download

TRANSCRIPT

Page 1: DDS In Action Part II

Angelo Corsaro, PhD Chief Technology Officer

ADLINK Technologies Inc. [email protected]

DDS in ActionPart-II

Page 2: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Recap

Page 3: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

What is it?

Page 4: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5DDS is a standard technology for ubiquitous, interoperable, secure, platform independent, and real-time data sharing across network connected devices

DDS in 131 characters

Page 5: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Who is using it?

Page 6: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Page 7: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Part II

Page 8: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Dynamic Discovery

Page 9: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Applications can autonomously and

asynchronously read and write data enjoying spatial and temporal decoupling

Virtualised Data Space

DDS Global Data Space

...

Data Writer

Data Writer

Data Writer

Data Reader

Data Reader

Data Reader

Data Reader

Data Writer

TopicAQoS

TopicBQoS

TopicCQoS

TopicDQoS

Page 10: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5DDS Dynamic discoveries is responsible for (1) uncovering DDS

applications, (2) matching interests and (3) setting up

data path between matching readers and

writers

Dynamic Discovery

DDS Global Data Space

...

Data Writer

Data Writer

Data Writer

Data Reader

Data Reader

Data Reader

Data Reader

Data Writer

TopicAQoS

TopicBQoS

TopicCQoS

TopicDQoS

Page 11: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Built-in dynamic discovery isolates applications from network topology

and connectivity details

Dynamic Discovery

DDS Global Data Space

...

Data Writer

Data Writer

Data Writer

Data Reader

Data Reader

Data Reader

Data Reader

Data Writer

TopicAQoS

TopicBQoS

TopicCQoS

TopicDQoS

Page 12: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Lab 1: Wireshark

Page 13: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Decomposing DDS

Page 14: DDS In Action Part II

Information Organisation

Page 15: DDS In Action Part II

Domain• DDS data lives within a domain

• A domain is identified with a non negative integer, such as 1, 3, 31

• The number 0 identifies the default domain

• A domain represent an impassable communication plane

DDS Domain

Page 16: DDS In Action Part II

Partitions• Partitions are the mechanism provided by DDS to

organise information within a domain

• Access to partitions is controlled through QoS Policies

• Partitions are defined as strings: • “system:telemetry”

• “system:log”

• “data:row-2:col-3”

• Partitions addressed by name or regular expressions: • ”system:telemetry”

• “data:row-2:col-*”

Partitions

Page 17: DDS In Action Part II

Information Definition

Page 18: DDS In Action Part II

Topic• A Topic defines a domain-wide information’s class

• A Topic is defined by means of a (name, type, qos) tuple, where

• name: identifies the topic within the domain

• type: is the programming language type associated with the topic. Types are extensible and evolvable

• qos: is a collection of policies that express the non-functional properties of this topic, e.g. reliability, persistence, etc.

TopicType

Name

QoS

Page 19: DDS In Action Part II

Topic and Instances• As explained in the previous slide a topic defines a class/type of information

• Topics can be defined as Singleton or can have multiple Instances

• Topic Instances are identified by means of the topic key

• A Topic Key is identified by a tuple of attributes -- like in databases

• Remarks:

• A Singleton topic has a single domain-wide instance

• A “regular” Topic can have as many instances as the number of different key values, e.g., if the key is an 8-bit character then the topic can have 256 different instances

Page 20: DDS In Action Part II

Example

Page 21: DDS In Action Part II

Active Floor

• Assume we are building an active floor

• This active floor is made by a matrix of pressure sensors used to detects position, and indirectly movement

• This information is leveraged by the application that uses the active floor for positioning or entertainment

Cell:(i,j)

Page 22: DDS In Action Part II

Active Floor• The generic active cell can be modelled

with a topic that has an instance for each value of (i,j). The topic type can be defined as:

• Each cell is now distinguishable and associated with a topic instance Cell:

(i,j)

structTCell{shortrow;shortcolumn;floatpressure;//inkPa};#pragmakeylistTCellrowcolumn

Page 23: DDS In Action Part II

Active Floor• How can we know when something is on the

cell?

• The detection can be based on the difference between the atmospheric pressure, say P0, and the pressure sensed by the cell

• We can model this as a Singleton Topic ReferencePressure defined by the type:

Cell:(i,j)

structTReferencePressure{floatpressure;//inkPafloatprecision;};#pragmakeylistTReferencePressure

Page 24: DDS In Action Part II

Active Floor• Each sensor has associated a

topic instance identified by the (row,column) coordinate -- the instance key

• Each instance produces a stream of pressure values that in DDS terms are called samples

0 1 2 3

0

1

2

3

4

Pressur

e

time

Pressur

e

time

Pressur

e

time

structTCell{shortrow;shortcolumn;floatpressure;//inkPa};#pragmakeylistCellrowcolumn

Page 25: DDS In Action Part II

Exercise

• What if we want to extend our model to deal with floors on different levels?

• How would you extend the data model?

• How would you use partitions?

1 2 3

Pressur

e

time

Pressur

e

time

Pressur

e

time

Page 26: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Producing Information

Page 27: DDS In Action Part II

Data Writer• A DataWriter (DW) is a strongly typed

entity used to produce samples for one or more instances of a Topic, with a given QoS

• Conceptually, the DataWriter QoS should be the same as the Topic QoS or more stringent

• However, DDS does enforce a specific relationship between the Topic and DataWriter QoS

TopicTypeName

QoS

Page 28: DDS In Action Part II

Data Writer

The DataWriter controls the life-cycle of Topic Instances and allows to:

• Define a new topic instance

• Write samples for a topic instance

• Dispose the topic instance

TopicTypeName

QoS

Page 29: DDS In Action Part II

The DataWriter controls the life-cycle of Topic Instances and allows to:

• Define a new topic instance

• Write samples for a topic instance

• Dispose the topic instance

TopicTypeName

QoS

Data Writer

Page 30: DDS In Action Part II

Writer CacheEach DDS DataWriter has an associated cache

• Writes are always local to the cache

• This cache provides two degrees of temporal decoupling between writers and readers. One w.r.t. processing speed the other w.r.t. temporal coupling

• The writer cache along with DDS QoS Policies provides built-in support for the Circuit-Breaker pattern

DataWriter Cache

DataWriter

...

Samples

Instances

Cache

Page 31: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Consuming Information

Page 32: DDS In Action Part II

Data Reader

• A DataReader (DR) is a strongly typed entity used to access and/or consume samples for a Topic, with a given QoS

• Conceptually, the DataReader QoS should be the same as the Topic QoS or less stringent

• However, DDS does enforce a specific relationship between the Topic and DataReader QoS

TopicTypeName

QoS

Page 33: DDS In Action Part II

Reader Cache

The Reader Cache stores the last n∊𝜨∞ samples for each relevant instance

Where: 𝜨∞=𝜨 ∪ {∞}

DataReader Cache

DataReader

...

Samples

Instances

Cache

Page 34: DDS In Action Part II

Data ReaderDepending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

0 1 2 3

0

1

2

3

4

Pressure time

Pressure time

Pressure time

Page 35: DDS In Action Part II

0 1 2 3

0

1

2

3

4

Pressure time

Pressure time

Pressure time

Depending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

n=3

3

Page 36: DDS In Action Part II

0 1 2 3

0

1

2

3

4

Pressure time

Pressure time

Pressure time

Data ReaderDepending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

n=3

Page 37: DDS In Action Part II

Data ReaderDepending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

n=3

0 1 2 3

0

1

2

3

4

Pressure time

Pressure time

Pressure time

Page 38: DDS In Action Part II

Data ReaderDepending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

n=3

0 1 2 3

0

1

2

3

4

Pressure time

Pressure time

Pressure time

Page 39: DDS In Action Part II

Data ReaderDepending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

0 1 2 3

0

1

2

3

4

n=3

Pressure time

Pressure time

Pressure time

Page 40: DDS In Action Part II

Data ReaderDepending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

0 1 2 3

0

1

2

3

4

n=3

Pressure time

Pressure time

Pressure time

Page 41: DDS In Action Part II

Data ReaderDepending on its QoS a DataReader may provide access to:

• last sample

• last n samples

• all samples produced since the DataReader was created

0 1 2 3

0

1

2

3

4

n=3

Pressure time

Pressure time

Pressure time

Page 42: DDS In Action Part II

Data Reader• Samples are stored in the DataReader

Cache

• Samples can be read or taken from the cache

• Samples taken are evicted from the cache

• Samples read remain in the cache and are simply market as read

• The cache content can be selected based on content or state. More on this later...

0 1 2 3

0

1

2

3

4

Pressure time

Pressure time

Pressure time

Page 43: DDS In Action Part II

Data Selection

Page 44: DDS In Action Part II

Reading Data

• The action of reading samples for a Reader Cache is non-destructive.

• Samples are not removed from the cache

DataReader Cache

DataReader

...

DataReader Cache

DataReader

...read

Page 45: DDS In Action Part II

Taking Data

• The action of taking samples for a Reader Cache is destructive.

• Samples are removed from the cache

DataReader Cache

DataReader

...

DataReader Cache

DataReader

...take

Page 46: DDS In Action Part II

Samples Selector

• Samples can be selected using composable content and status predicates DataReader Cache

DataReader

...

Page 47: DDS In Action Part II

Content Filtering

• Filters allow to control what gets into a DataReader cache

• Filters are expressed as SQL where clauses or as Java/C/JavaScript predicates

DataReader Cache

DataReader

...

Filter

Application

Network

Page 48: DDS In Action Part II

Content Filters

Content Filters can be used to project on the local cache only the Topic data satisfying a given predicate

structCarDynamics{@keystringcid;longx;longy;floatdx;longdy;}

cid x y dx dyGR 33N GO 167 240 45 0LO 00V IN 65 26 65 0AN 637 OS 32 853 0 50AB 123 CD 325 235 80 0

“dx>50ORdy>50”

Type

CarDynamics

cid x y dx dyLO 00V IN 65 26 65 0AB 123 CD 325 235 80 0

Reader Cache

Page 49: DDS In Action Part II

Content-Based Selection

• Queries allow to control what gets out of a DataReader Cache

• Queries are expressed as SQL where clauses or as Java/C/JavaScript predicates DataReader Cache

DataReader

...

Query

DataReader Cache

DataReader

...

Application

Network

Page 50: DDS In Action Part II

Queries

Queries can be used to select out of the local cache the data matching a given predicate

Reader Cache

structCarDynamics{@keystringcid;longx;longy;floatdx;longdy;}

cid x y dx dyGR 33N GO 167 240 45 0LO 00V IN 65 26 65 0AN 637 OS 32 853 0 50AB 123 CD 325 235 80 0

“dx>50ORdy>50”

Type

CarDynamics

cid x y dx dyGR 33N GO 167 240 45 0LO 00V IN 65 26 65 0AN 637 OS 32 853 0 50AB 123 CD 325 235 80 0

cid x y dx dyLO 00V IN 65 26 65 0AB 123 CD 325 235 80 0

query

Page 51: DDS In Action Part II

Copyrig

ht2013,PrismTech–A

llRightsReserved.

Sample, Instance, and View State

• The samples included in the DataReader cache have associated some meta-information which, among other things, describes the status of the sample and its associated stream/instance

• The Sample State (READ, NOT_READ) allows to distinguish between new samples and samples that have already been read

• The View State (NEW, NOT_NEW) allows to distinguish a new instance from an existing one

• The Instance State (ALIVE, NOT_ALIVE_DISPOSED, NOT_ALIVE_NO_WRITERS) allows to track the life-cycle transitions of the instance to which a sample belongs

Page 52: DDS In Action Part II

State-Based Selection

• State based selection allows to control what gets out of a DataReader Cache

• State base selectors predicate on samples meta-information DataReader Cache

DataReader

...

State Selector

DataReader Cache

DataReader

...

Application

Network

Page 53: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Interaction Models

Page 54: DDS In Action Part II

Copyrig

ht2013,PrismTech–A

llRightsReserved.

Interaction ModelsPolling

•The application proactively polls for data availability as well as special events, such as a deadline being missed, etc. Notice that all DDS API calls, exclusion made for wait operations, are non-blocking

Synchronous Notification

•The application synchronously waits for some conditions to be verified, e.g., data availability, instance lifecycle change, etc.

Asynchronous Notification

•The application registers the interest to be asynchronously notified when specific condition are satisfied, e.g. data available, a publication matched, etc.

Page 55: DDS In Action Part II

Copyrig

ht2013,PrismTech–A

llRightsReserved.

Synchronous Notifications

• DDS provides a mechanism known as WaitSet to synchronously wait for a condition

• Condition can predicate on:

• communication statuses

• data availability

• data availability with specific content

• user-triggered conditions

Page 56: DDS In Action Part II

Copyrig

ht2013,PrismTech–A

llRightsReserved.

Asynchronous Notifications

• DDS provides a mechanism known as Listeners for asynchronous notification of a given condition

• Listener interest can predicate on:

• communication statuses

• data availability

Page 57: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Putting it all together

Page 58: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Anatomy of a DDS Application

Page 59: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Writing Data in C++#include <dds.hpp>

int main(int, char**) {

DomainParticipant dp(0); Topic<Meter> topic(“SmartMeter”); Publisher pub(dp); DataWriter<Meter> dw(pub, topic);

while (!done) { auto value = readMeter() dw.write(value); std::this_thread::sleep_for(SAMPLING_PERIOD); }

return 0; }

enumUtilityKind{ ELECTRICITY, GAS, WATER};structMeter{ stringsn; UtilityKindutility; floatreading; floaterror;};#pragmakeylistMetersn

Page 60: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Reading Data in C++#include <dds.hpp>

int main(int, char**) {

DomainParticipant dp(0); Topic<Meter> topic(”SmartMeter”); Subscriber sub(dp); DataReader<Meter> dr(dp, topic);

LambdaDataReaderListener<DataReader<Meter>> lst; lst.data_available = [](DataReader<Meter>& dr) { auto samples = data.read(); std::for_each(samples.begin(), samples.end(), [](Sample<Meter>& sample) { std::cout << sample.data() << std::endl; } } dr.listener(lst); // Print incoming data up to when the user does a Ctrl-C std::this_thread::join(); return 0;

}

enumUtilityKind{ ELECTRICITY, GAS, WATER};structMeter{ stringsn; UtilityKindutility; floatreading; floaterror;};#pragmakeylistMetersn

Page 61: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Writing Data in Scalaimport dds._import dds.prelude._import dds.config.DefaultEntities._

object SmartMeter { def main(args: Array[String]): Unit = { val topic = Topic[Meter](“SmartMeter”) val dw = DataWriter[Meter](topic) while (!done) { val meter = readMeter() dw.write(meter) Thread.sleep(SAMPLING_PERIOD) } }}

enumUtilityKind{ ELECTRICITY, GAS, WATER};structMeter{ stringsn; UtilityKindutility; floatreading; floaterror;};#pragmakeylistMetersn

Page 62: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Reading Data in Scalaimport dds._import dds.prelude._import dds.config.DefaultEntities._

object SmartMeterLog { def main(args: Array[String]): Unit = { val topic = Topic[Meter](“SmartMeter”) val dr = DataReader[Meter](topic) dr listen { case DataAvailable(_) => dr.read.foreach(println) } }}

enumUtilityKind{ ELECTRICITY, GAS, WATER};structMeter{ stringsn; UtilityKindutility; floatreading; floaterror;};#pragmakeylistMetersn

Page 63: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Writing Data in Python

import dds import timeif __name__ == '__main__': topic = dds.Topic("SmartMeter", "Meter") dw = dds.Writer(topic) while True: m = readMeter() dw.write(m) time.sleep(0.1)

enumUtilityKind{ ELECTRICITY, GAS, WATER};structMeter{ stringsn; UtilityKindutility; floatreading; floaterror;};#pragmakeylistMetersn

Page 64: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Reading Data in Pythonimport ddsimport sys def readData(dr): samples = dds.range(dr.read()) for s in samples: sys.stdout.write(str(s.getData())) if __name__ == '__main__': t = dds.Topic("SmartMeter", "Meter") dr = dds.Reader(t) dr.onDataAvailable = readData

enumUtilityKind{ ELECTRICITY, GAS, WATER};structMeter{ stringsn; UtilityKindutility; floatreading; floaterror;};#pragmakeylistMetersn

Page 65: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Lab2: Code Walkthrough

Page 66: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Performance

Page 67: DDS In Action Part II

LatencyVortex DDS latency can be as low as ~30 usec

This is the lowest among DDS implementations several times better than what can be obtained with MQTT, AMQP, OPC-UA

Page 68: DDS In Action Part II

Throughput

Vortex DDS can easily saturate a 10Gbps network

Vortex throughput is 2-3x better than competing technologies

Page 69: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Lab3: Performance Eval.

Page 70: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

Concluding Remarks

Page 71: DDS In Action Part II

Cop

yrig

ht P

rism

Tech

, 201

5

DDS provides a very high level abstractions to architect and implement distributed systems

DDS has built-in support for several patterns that are essential to keep systems working at scale, such as circuit-breakers and temporal decoupling

DDS can address the most challenging environment w.r.t. volumes, latencies and scale

Wrapping Up

Page 72: DDS In Action Part II