nullOverview of the OMG
Data Distribution ServiceOverview of the OMG
Data Distribution ServiceDouglas C. Schmidt & Jeff Parsons
{schmidt,parsons}@dre.vanderbilt.edu
http://www.dre.vanderbilt.edu/~schmidt/ Professor of EECS Vanderbilt University Nashville, TennesseePast R&D Successes: Platform-centric SystemsPast R&D Successes: Platform-centric SystemsLegacy DoD systems are designed to be:
Stovepiped
Proprietary
Brittle & non-adaptive
Expensive to develop & evolve
VulnerableFrom this design paradigm…Air
FrameAPNavWTSGPSIFFFLIRCyclic
ExecProblem: Small changes can break nearly anything & everythingPast R&D Successes: Platform-centric SystemsPast R&D Successes: Platform-centric Systems…and this operation paradigm…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 staticallyProblem: Lack of any resource can break nearly anything & everythingPast R&D Successes: Network-centric SystemsPast R&D Successes: Network-centric Systems…to this design paradigm…Event
ChannelReplication
ServiceGPSIFFFLIRObject Request BrokerAir
FrameAPNavWTSToday’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
VulnerableProblem: Unanticipated changes can break many thingsPast R&D Successes: Network-centric SystemsPast R&D Successes: Network-centric Systems…and this operational paradigm…EndsystemApplicationsEndsystemApplicationsMechanism & Property
ManagersSys CondSys CondSys CondInterceptorInterceptorLocal
Resource
ManagersSys Cond{}QoS ContractsQoS ContractsNetwork latency
& bandwidthWorkload &
ReplicasCPU & memoryConnections &
priority bandsNetwork latency
& bandwidthWorkload &
ReplicasCPU & memoryConnections &
priority bandsLocal
Resource
ManagersAdaptive Real-time MiddlewarePast R&D Successes: Network-centric SystemsPast R&D Successes: Network-centric Systems…and this operational paradigm…Problem: Network-centricity is an afterthought in today’s systemsNew Demands on Enterprise DRE SystemsNew Demands on Enterprise DRE SystemsKey challenges in the problem space
Network-centric, dynamic, very large-scale “systems of systems”
Stringent simultaneous quality of service (QoS) demands
Highly diverse & complex problem domainsCase Study: QoS-enabled Publish/Subscribe Technologies for Tactical Information ManagementCoordination
Of Multiple UAVsDynamic Mission
ReplanningFeedback &
ControlImage Processing
& TrackingCase Study: QoS-enabled Publish/Subscribe Technologies for Tactical Information ManagementDARPA PCES Capstone demo, 4/14/05, White Sands Missile RangeCase Study: QoS-enabled Publish/Subscribe Technologies for Tactical Information ManagementCoordination
Of Multiple UAVsDynamic Mission
ReplanningFeedback &
ControlImage Processing
& TrackingCase Study: QoS-enabled Publish/Subscribe Technologies for Tactical Information ManagementModeling ToolsModel CheckingReal-time JVMsReal-time ORBsAspect LanguagesLimitations with Demo’d PCES
Information Management TechnologiesLimitations with Demo’d PCES
Information Management TechnologiesShooter 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.Problem: Net-centricity is afterthought in platform-centric technologiesLimitations with Demo’d PCES
Information Management TechnologiesLimitations with Demo’d PCES
Information Management TechnologiesC2 & C4ISR information management based on J2EE & Java Messaging Service (JMS)
Best suited for operational enterprise environments
e.g., large data centers connect via wireline networks
Poorly suited for tactical environments
e.g., lack of QoS policies & RTOS integration, extremely high time/space overheadJava Messaging
ServiceEnterprise
Network & OSJ2EE
MiddlewareTrack
ProcessingProblem: Enterprise technologies are ill suited for tactical systemsOur R&D Goal: Evaluate QoS-enabled Info Brokering for Tactical Systems 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 systemsGoal is “better than best-effort,” subject to resource constraints…Overview of the Data Distribution Service (DDS)DDS is an highly efficient OMG pub/sub standard
e.g., fewer layers, less overhead Data Reader RData Writer RPublisherSubscriberTopic
ROverview of the Data Distribution Service (DDS)Tactical
Network & RTOSDDS Pub/Sub
InfrastructureRT Info to Cockpit & Track ProcessingOverview 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 Data Reader RData Writer RPublisherSubscriberTopic
RNEW TOPICNEW
SUBSCRIBEROverview of the Data Distribution Service (DDS)NEW
PUBLISHEROverview 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 layersData Reader RData Writer RPublisherSubscriberS1S2S3S4S5S6S7S6S5S4S3S2S1Topic
RS7S7XHISTORYRELIABILITYCOHERENCYRESOURCE LIMITSLATENCYOverview of the Data Distribution Service (DDS)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 dataData Reader RData Writer RPublisherSubscriberS1S2S3S4S5S6S7Topic
RSOURCE
FILTERDESTINATION
FILTEROverview of the Data Distribution Service (DDS)TIME-BASED
FILTERPromising Approach:
The OMG Data Distribution Service (DDS)Promising Approach:
The OMG Data Distribution Service (DDS)ApplicationApplicationApplicationApplicationApplication‘Global’ Data StorereadreadreadwritewritewritewriteDDS provides flexibility, power, & modular structure by decoupling:
Location – anonymous pub/sub
Redundancy – any number of readers & writers
QoS – async, disconnected, time-sensitive, scalable, & reliable data distribution at multiple layers
Platform & protocols – portable & interoperableNetwork latency
& bandwidthWorkload &
ReplicasCPU & memoryConnections &
priority bandsDDS Architectural ElementsDDS Architectural ElementsData-Centric Publish-Subscribe (DCPS)
The lower layer APIs apps can use to exchange topic data with other DDS-enabled apps according to designated QoS policiesData Local Reconstruction Layer (DLRL)
The upper layer APIs that define how to build a local object cache so apps can access topic data as if it were localDDS 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 resourcesDDS Application ArchitectureDDS Application ArchitectureDCPSApplicationDLRLApplicationDLRLApplicationDLRLApplicationDLRLCommunication The Application{DDS Domains & Domain ParticipantsDDS Domains & Domain Participants12312311DomainParticipantNodeNodeNodeNodeNodeNodeThe domain is the basic construct used to bind individual applications together for communication
Like a VPN DCPS EntitiesDCPS Entities include
Topics
Typed data
Publishers
Contain DataWriters
Subscribers
Contain DataReaders
DomainParticipants
Entry points
DCPS EntitiesData can be accessed in two ways
Wait-based (synchronous calls)
Listener-based (asynchronous callbacks)
Sophisticated support for filtering
e.g., Topic, Content-FilteredTopic, or MultiTopic
Configurable via (many) QoS policiesTopicTopicTopicData ReaderData WriterData WriterData ReaderData ReaderData WriterSubscriberPublisherPublisherSubscriberData DomainDomain ParticipantQoS Policies Supported by DDSQoS Policies Supported by DDSDCPS entities (i.e., topics, data readers/writers) configurable via QoS policies
QoS tailored to data distribution in tactical information systems
Request/offered compatibility checked by DDSDEADLINE
Establishes contract regarding rate at which periodic data is refreshed
LATENCY_BUDGET
Establishes guidelines for acceptable end-to-end delays
TIME_BASED_FILTER
Mediates exchanges between slow consumers & fast producers
RESOURCE_LIMITS
Controls resources utilized by serviceRELIABILITY (BEST_EFFORT, RELIABLE)
Enables use of real-time transports for data
HISTORY (KEEP_LAST, KEEP_ALL)
Controls which (of multiple) data values are delivered
DURABILITY (VOLATILE, TRANSIENT, PERSISTENT)
Determines if data outlives time when they are written
… and many more …Best Effort Reliability QoS in DDSBest Effort Reliability QoS in DDSPublisherSubscriberSubscriberSubscriberQoS Reliability = BEST_EFFORTNotification of new data objectsno notificationnotificationtimetime-based filterdeadlinetimeout Very predictable
Data is sent without reply
Publishers and subscribers match and obey QoS Deadline policy settings
Time-based Filter QoS policy gives bandwidth controlReliable QoS in DDSReliable QoS in DDSQoS Reliability = RELIABLETopic
RData Reader RData Writer RPublisherSubscriberhistoryS1S2S3S4S5S6S7S7S6S5S4S3S2S1Ordered instance delivery is guaranteedTradeoff Between Reliability & DeterminismTradeoff Between Reliability & DeterminismXXXQoS Reliability = RELIABLEQoS Reliability = BEST_EFFORT Can’t have reliability and determinism.
Best effort mode for streaming data.
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.
DDS reliability is tunable.
Can be adjusted per subscription.All QoS Policies in DDSAll QoS Policies in DDSDeadline
Destination Order
Durability
Entity Factory
Group Data
History
Latency Budget
Lifespan
Liveliness
Ownership
Ownership StrengthPartition
Presentation
Reader Data Lifecycle
Reliability
Resource Limits
Time-Based Filter
Topic Data
Transport Priority
User Data
Writer Data LifecycleSingle vs. Multiple Domain SystemsSingle vs. Multiple Domain SystemsData Writers & PublishersData Writers & PublishersData 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 desireData Readers & SubscribersData Readers & SubscribersA 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)Types & KeysTypes & KeysA 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
TopicsTopicsA 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 content-based subscriptions.
MultiTopics correspond to SQL join
Content-Filtered Topics correspond to SQL select.Domain ID 35 Topic name “MySensor” Type string sensor_id [ key ] float value “AnalogSensor” name Topic-Based Publish/SubscribeTopic-Based Publish/SubscribeDataWriter 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”, respectivelyPressureTemperatureSubscription = Topic + DataReaderSubscription = Topic + DataReaderContent-based SubscriptionsContent-based SubscriptionsContentFilteredTopic (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 data-format
e.g. combine subscription to “Pressure” & “Temperature” & re-arrange the data into a new type:
struct { float pres; float temp; };DDS Content-Filtered TopicsDDS Content-Filtered TopicsContent-Filtered TopicTopicFilter Expression: Value > 260Expression ParamsTopic Instances in DomainInstance 1Instance 2Instance 3Instance 4Instance 5Instance 6Instance 7Value = 249Value = 230Value = 275Value = 262Value = 258Value = 261Value = 259Filter Expression and Expression Params determine which Topic instances the Subscriber receives.DDS MultiTopic SubscriptionsDDS MultiTopic SubscriptionsTopicTopicTopicTopicMultiTopicData ReaderData ReaderData ReaderData ReaderSubscriberSubscriberSubscriberMultiTopics can combine, filter, and rearrange data from multiple Topics.Domain ParticipantDomain ParticipantExample: Create Domain ParticipantExample: Create Domain Participant// 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); DomainParticipant object acts as factory for Publisher, Subscriber, Topic and MultiTopic entity objectsExample: Create TopicExample: 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 listenerExample: Create Subscriber and DataReaderExample: 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 ());Example: Create Publisher and DataWriterExample: 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);How to Get Data (Async Listener-based)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
……
}How to Get Data (Sync Wait-based)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_dataBenchmark ScenarioBenchmark ScenarioTwo 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.Testbed ConfigurationTestbed ConfigurationHostname
blade14.isislab.vanderbilt.edu
OS version (uname -a)
Linux version 2.6.14-1.1637_FC4smp (bhcompile@hs20-bc1-4.build.redhat.com)
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 ramTest ParametersTest ParametersAverage 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
// Complex Sequence Type
struct Inner {
string info;
long index;
};
typedef sequence InnerSeq;
struct Outer {
long length;
InnerSeq nested_member;
};
typedef sequence ComplexSeq;Roundtrip Latency Results (1/2)Roundtrip Latency Results (1/2)Roundtrip Latency Results (2/2)Roundtrip Latency Results (2/2)Roundtrip Latency Results AnalysisRoundtrip Latency Results AnalysisFrom 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.Encoding/Decoding Benchmarks 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 benchmarksEncoding/Decoding Results (1/2)Encoding/Decoding Results (1/2)Encoding/Decoding Results (2/2)Encoding/Decoding Results (2/2)Encoding/Decoding Results AnalysisEncoding/Decoding Results AnalysisSlowest DDS
本文档为【DDS】,请使用软件OFFICE或WPS软件打开。作品中的文字与图均可以修改和编辑,
图片更改请在作品中右键图片并更换,文字修改请直接点击文字进行修改,也可以新增和删除文档中的内容。
该文档来自用户分享,如有侵权行为请发邮件ishare@vip.sina.com联系网站客服,我们会及时删除。
[版权声明] 本站所有资料为用户分享产生,若发现您的权利被侵害,请联系客服邮件isharekefu@iask.cn,我们尽快处理。
本作品所展示的图片、画像、字体、音乐的版权可能需版权方额外授权,请谨慎使用。
网站提供的党政主题相关内容(国旗、国徽、党徽..)目的在于配合国家政策宣传,仅限个人学习分享使用,禁止用于任何广告和商用目的。