Twin Oaks Computing, Inc.CoreDX DDSTechnical Brief                            Jul 2012
What is CoreDX DDS?   CoreDX DDS is a Communications    Middleware     Eases development and deployment of     Distribut...
CoreDX DDS Publish /            Subscribe Middleware   Message Oriented Middleware          DDS extends MOM concepts    ...
CoreDX DDS Architecture   DomainParticipant     Associated with a      Domain     Communicates with      other      Dom...
Standards Based Data            Communication   Object Management Group manages DDS standards:     DDS API: Data Distrib...
Technical FeaturesDynamic Discovery        Cross-platformReliability              InteroperabilityDurability              ...
CoreDX DDS Features:          Dynamic Discovery   DDS Dynamic Discovery is powerful and useful     Built-in to all CoreD...
CoreDX DDS Features:           Dynamic Discovery (cont)   CoreDX DDS Applications (DomainParticipants)     Automatically...
CoreDX DDS Features:           Quality of Service Policies   QoS Policies tailor the behavior of data    communications  ...
CoreDX DDS Features:           Efficient Reliability: Overview   CoreDX DDS provides configurable Reliable    data commun...
CoreDX DDS Features:              Efficient Reliability: Protocol                       01      RELIABLE Guarantees:      ...
CoreDX DDS Features:           Efficient Reliability: Example                                                    One dropp...
CoreDX DDS Features:           Durability   CoreDX DDS provides configurable Durable data    communications   CoreDX DDS...
CoreDX DDS Features:               Durability: Example   Durability Example                Data              Producer    ...
CoreDX DDS Features:           Historical Data Caches   Each Data Reader and Data Writer maintains a Data Cache   Data R...
CoreDX DDS Features:           Filtering   Kinds of Filters:     Content Filters are specified by an SQL-like query     ...
CoreDX DDS Features:           Filtering (cont)   Filters are configurable     By each Reader     Applied at the Writer...
CoreDX DDS Features:           Ownership   CoreDX DDS provides configurable Ownership of published    data     Shared: R...
CoreDX DDS Features:            Cross-platform, and more   Cross-Platform communications:       x86 (32 & 64 bit), Ultra...
CoreDX DDS Features:        Portability   Portable across languages     Common API defined for multiple languages   Por...
CoreDX DDS Features:          Interoperability   What is it?     The ability of DDS implementations from different      ...
CoreDX DDS:            Source Code: Portable, Certifiable    Features:      Minimal Lines of Source Code       ▪ Entire ...
CoreDX DDS:         Performance: Throughput, LatencyNo Performance Sacrifice                                          Perf...
CoreDX DDS:              Performance: CPU, NetworkLong running throughput  test     • TX1024 byte messages     • Total thr...
CoreDX DDS:            Small Run-time Memory Requirements    CoreDX DDS run-time memory requirements          Local Entit...
CoreDX DDS:                Small Library Code Size        Minimal Binary Code Size          Measured in Kilobytes (not M...
CoreDX DDS Features:           Configurability   DDS API includes specific policies for tailoring    communication behavi...
Comparisons DDS JMS Web Services XMPP
Comparison:           DDS and JMSlookup ConnectionFactory            JNDI           lookup ConnectionFactorycreate Connect...
DDS and JMSFeature            JMS                             DDSArchitecture       Publish subscribe               Publis...
Comparison:           DDS and SOA Web Services          Web Server                                                        ...
DDS and SOA Web ServicesFeature            Web Services                     DDSArchitecture       Message oriented Middlew...
For More Information   Visit our Website    http://www.twinoakscomputing.com for:     Quick Start Guides     Free Evalu...
Summary    Common, Complex Communication Requirements:      Where do I get my data?      How often?      What happens ...
Questions?
Upcoming SlideShare
Loading in …5
×

CoreDX DDS Technical Information

828 views

Published on

Published in: Technology, Education
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
828
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
17
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • “All this, and No tradeoff in performance”These are graphs of performance benchmarks run over a Gbit ETHERNET network. As you can see, these numbers are pretty good.Throughput is above 900 Mbps, and latency is around 75 microsecs
  • “All this, and No tradeoff in performance”
  • CoreDX DDS Technical Information

    1. 1. Twin Oaks Computing, Inc.CoreDX DDSTechnical Brief Jul 2012
    2. 2. What is CoreDX DDS? CoreDX DDS is a Communications Middleware  Eases development and deployment of Distributed Applications  Supports interoperable communications  High Throughput with Low Latency  Insulates Application from Communication Details
    3. 3. CoreDX DDS Publish / Subscribe Middleware Message Oriented Middleware  DDS extends MOM concepts  A Publisher Generates Data  Adds Strong Data Typing  A Subscriber Accesses Data  Adds Quality of Service Policies  The Middleware Manages the ▪ Reliability / History / Durability / Connections and the Data Filtering Publisher and Subscriber are  Formalized Standard (API and Wire Protocol) Loosely Coupled ▪ Portable / Interoperable between Vendors Subscriber Publisher Data SubscriberPublisher Topic Subscriber Data Type QoS
    4. 4. CoreDX DDS Architecture DomainParticipant  Associated with a Domain  Communicates with other DomainParticipants in the same Domain  Contains DataReaders, DataWriters, and Topics A DataWriter publishes data on a Topic A DataReader subscribes to a Topic Each Topic has a Defined Data Type
    5. 5. Standards Based Data Communication Object Management Group manages DDS standards:  DDS API: Data Distribution Service ▪ Entities ▪ QoS Policies ▪ Asynchronous and Synchronous notifications ▪ Data Types  DDS Language Bindings:  DDS Wire Protocol: Real-Time Publish Subscribe (RTPS) Wire Protocol ▪ Discovery ▪ Reliability ▪ Data Encoding  DDS-Related Technologies ▪ Extensible Types ▪ Web Enabled DDS (in work) ▪ DDS Security (in work)
    6. 6. Technical FeaturesDynamic Discovery Cross-platformReliability InteroperabilityDurability PortabilityHistorical Data Caches High PerformanceFiltering Highly ConfigurableOwnership
    7. 7. CoreDX DDS Features: Dynamic Discovery DDS Dynamic Discovery is powerful and useful  Built-in to all CoreDX DDS Applications ▪ CoreDX DDS applications publish and subscribe to data without configuring endpoints ▪ CoreDX DDS Entities do not require knowledge of other DDS Entities they may be communicating with  Interoperable between DDS implementations ▪ Applications built on compliant DDS implementations will automatically discover each other  Automatic ▪ No special configuration required ▪ Simply create DDS Entities
    8. 8. CoreDX DDS Features: Dynamic Discovery (cont) CoreDX DDS Applications (DomainParticipants)  Automatically discover each other  Exchange network information ▪ IP addresses for multicast and unicast data transfers Producers and Consumers (DataWriters, DataReaders)  Automatically discover each other  Exchange configuration information  Determine if data exchange is appropriate ▪ Do Topics match? ▪ Do Data Types match? ▪ Do communication behavior expectations match?  If so, enable data exchange
    9. 9. CoreDX DDS Features: Quality of Service Policies QoS Policies tailor the behavior of data communications  What are the reliability requirements?  How long is data saved for possible future publication or future access by the application? ▪ What are the storage requirements?  What are the timing requirements?  How should data be presented to subscribers?  Should data be filtered?  Are there redundancy or failover requirements? DDS specifies 22 distinct QoS Policies Twin Oaks Computing, Inc. PROPRIETARY
    10. 10. CoreDX DDS Features: Efficient Reliability: Overview CoreDX DDS provides configurable Reliable data communications  Even on unreliable networks (e.g. wireless)  Using UDP (MULTICAST and UNICAST) CoreDX DDS Reliability Addresses  Dropped Packets  Out of Order Samples  Communication Disconnects  Application Re-Starts
    11. 11. CoreDX DDS Features: Efficient Reliability: Protocol 01 RELIABLE Guarantees: 01 02 02 Data 03 • Delivery and Order Data 03 Writer 04 Reader 04 05 BEST EFFORT Guarantees: 05 06 • Order 06 07 07 07 06 05 04 03 02 01 Configurable Heartbeat and  Performance monitored by ACK/NACK interval readers and writers  Avoid packet storms  Flexible handling of slow readers Configuration items to balance  Dynamically remove slow readers latency and overhead  Heartbeats, delays, resource limits
    12. 12. CoreDX DDS Features: Efficient Reliability: Example One dropped Writer sends Heartbeats sample  Heartbeats can be sent with DATA messages Writer Reader Reader returns ACK/NACK 01 01  Missed samples detected by Reader 02 02 01  NACK Indicate specific missing 03 03 + HB 02 samples 04 03 04 ACK (1,3),  Combined with ACK to NACK [2] 04 acknowledge other samples 05 05 02 05 Writer can send Data using 06 06 + HB MULTICAST 07 07 06  Repairs are sent UNICAST ACK (6) 07 Reader delivers samples to the application in order
    13. 13. CoreDX DDS Features: Durability CoreDX DDS provides configurable Durable data communications CoreDX DDS Durability addresses  How long data is saved by Data Writers  If previously published data is sent to „late joining‟ DataReaders Durability Options  Volatile: Published data is saved just long enough to be sent to currently matched Readers  Transient Local: Published data is saved for as long as the Data Writer is alive (until application exit)  Transient, Persistent: Published data is saved by an external service, through application restarts, machine reboots
    14. 14. CoreDX DDS Features: Durability: Example Durability Example Data Producer S1 S3 Data published with Durability = TRANSIENT_LOCAL S2 S4Subscribing to data with Subscribing to data with S4 S2Durability = VOLITILE Durability = S4 TRANSIENT_LOCAL S2 S1 Data Data Consumer 1 Consumer 2
    15. 15. CoreDX DDS Features: Historical Data Caches Each Data Reader and Data Writer maintains a Data Cache Data Reader Cache  Holds received data to be delivered to the application  Can be sized and configured to save received data for later use  Multiple ways to access received data  CoreDX DDS „loans‟ data to the application ▪ Improves performance ▪ Eliminates extra data copy Data Writer Cache  Holds published data to be written on the wire  Can be sized and configured to save historical data to be delivered to late joining Readers
    16. 16. CoreDX DDS Features: Filtering Kinds of Filters:  Content Filters are specified by an SQL-like query ▪ Same syntax as the “WHERE” clause in an SQL query  Time Based Filters are specified by a duration for minimum separate between samples  Read Filters allow the application to „read‟ specific kinds of data from the Data Cache ▪ Previously seen / Not seen ▪ New data / Old data ▪ Alive / Dead ▪ Matching a content-based query
    17. 17. CoreDX DDS Features: Filtering (cont) Filters are configurable  By each Reader  Applied at the Writer or Reader Filters can reduce network and CPU load  Filter applied at the Writer ▪ Writer can send only the data requested by a Reader (UNICAST) ▪ Other Readers do not „wake up‟ to receive/process unwanted data  Filter applied at the Reader ▪ Writer can MULTICAST data to all Readers ▪ All Readers will „wake up‟ to receive / apply filters to data
    18. 18. CoreDX DDS Features: Ownership CoreDX DDS provides configurable Ownership of published data  Shared: Readers receive (duplicate) data from all Writers  Exclusive: Readers receive one copy of data, even when multiple Writers are publishing (duplicate) data Data Data Producer 1 Producer 2 S1 Ownership.kind = EXCLUSIVE S2 Ownership.kind = EXCLUSIVE Ownership.strength = 10 Ownership.strength = 5 S1 The consumer will see data from S2 only the strongest producer. S1 Data Consumer
    19. 19. CoreDX DDS Features: Cross-platform, and more Cross-Platform communications:  x86 (32 & 64 bit), UltraSPARC, ARMv5, ARVMv7, PPC, MIPS, Microblaze, FPGAs Cross-Operating System communications:  Linux, Windows, Solaris, QNX, VxWorks, NexusWare, LynxOS, Android, Unison Cross-Language communications:  C, C++, C#, Java
    20. 20. CoreDX DDS Features: Portability Portable across languages  Common API defined for multiple languages Portable across Operating Systems  Same programming experience on all operating systems Portable across vendors  Standardized API
    21. 21. CoreDX DDS Features: Interoperability What is it?  The ability of DDS implementations from different vendors/sources to communicate Why do we want it?  Increased flexibility in implementation decisions  Vendor independence Open Standards from the OMG allow for Interoperability  DDS API  RTPS Wire protocol Vendors commit to and test Interoperability ▪ Twin Oaks Computing, RTI, (partial) Prism Tech, Gallium
    22. 22. CoreDX DDS: Source Code: Portable, Certifiable  Features:  Minimal Lines of Source Code ▪ Entire „C‟ CoreDX DDS library < 35K SLOC ▪ Safety Critical Edition < 13K SLOC  Completely Native Source Code ▪ No 3rd party products or packages  Made in the USA ▪ All CoreDX product development performed in the United States, by United States Citizens  Minimal dependencies on Operating System libraries  Benefits:  Eases analysis and certification of baseline  EASY TO PORT TO ANY PLATFORM: Enterprise to Bare-Metal operating systems Twin Oaks Computing, Inc22 PROPRIETARY
    23. 23. CoreDX DDS: Performance: Throughput, LatencyNo Performance Sacrifice Performance Summary: • Throughput > 900 Mbps • Latency < 70 usec Twin Oaks Computing, Inc23 PROPRIETARY
    24. 24. CoreDX DDS: Performance: CPU, NetworkLong running throughput test • TX1024 byte messages • Total throughput of over 700 Megabits/sec • CPU utilization of a single core • doesn‟t exceed 30% • machine has 4 cores • Equates to less than 10% of total CPU Twin Oaks Computing, Inc24 PROPRIETARY
    25. 25. CoreDX DDS: Small Run-time Memory Requirements  CoreDX DDS run-time memory requirements Local Entity Local Entity Remote (Discovered) Size (bytes) Entity Size (bytes) DomainParticipant * 12000 2100 DataReader 3200 2500 DataWriter 3200 2400 Topic 750 0  For example: An application with * DomainParticipant size includes ▪ 1 DomainParticipant, all built-in Topics, DataWriters, ▪ 6 DataWriters, and and DataReaders ▪ 4 DataReaders will require <100KB Heap Memory Twin Oaks Computing, Inc25 PROPRIETARY
    26. 26. CoreDX DDS: Small Library Code Size  Minimal Binary Code Size  Measured in Kilobytes (not Megabytes!)  CoreDX “DDS Ping” application: 250 KB  Complete CoreDX DDS C library < 500KB  Conserves valuable Static RAM / Flash  Critical for embedded devices  Examples  Gumstix COMs  OMAP L138  Android based phones and tablets  FPGA‟s Twin Oaks Computing, Inc26 PROPRIETARY
    27. 27. CoreDX DDS Features: Configurability DDS API includes specific policies for tailoring communication behavior. Deadline Latency Budget Reliability Destination Order Lifespan Resource Limits Durability Liveliness Time Based Filter Entity Factory Ownership Topic Data Group Data Partition User Data History Reader Data Lifecycle Writer Data Lifecycle In addition, CoreDX DDS allows configuration of: Transport Threads Discovery Memory Usage Reliability Logging
    28. 28. Comparisons DDS JMS Web Services XMPP
    29. 29. Comparison: DDS and JMSlookup ConnectionFactory JNDI lookup ConnectionFactorycreate Connection create Connectioncreate Session create Sessioncreate MessageProducer JMS create MessageConsumerstart the Connection Server start the Connectionwrite data read dataJMS requires a Server that must JMS Server often requiresbe configured and connected significant resources, and creates a single point of failurecreate a DDS Participantcreate a Topic create a DDS participantcreate a Publisher create a Topiccreate a DataWriter create a Subscriberwrite data create a DataReaderEach DDS application contains all read datanecessary code for discovery andcommunications, no serverrequired
    30. 30. DDS and JMSFeature JMS DDSArchitecture Publish subscribe Publish subscribe (multicast)Platform Same API is exposed for all HW, Same API is exposed for all HW,Independence OS, and languages supported OS, and languages supportedDiscovery of JNDI and JMS servers must be Dynamic Discovery, no need toendpoints specified and configured specify where endpoints resideType Safety Generic Objects and XML are Strong type safety, application not type safe calls write() and read() with a specific data typeTailoring Limited ability to tailor QoS policies allow for easycommunication communications tailoring of communicationbehavior behaviorsInteroperability None Open standard with proven interoperability
    31. 31. Comparison: DDS and SOA Web Services Web Server create Serviceenable web services configure Server Addressinstall web service Web call Service Service get responseA web server must be configured The client must be configured withto provide web services, and the the address of the web serverweb service must be installed before the service can be calledcreate a DDS Participant create a DDS participantcreate a Topic create a Topiccreate a Publisher create a Subscribercreate a DataWriter create a DataReaderwrite data read data Each DDS application contains all necessary code for discovery and communications, no server or end point configuration required
    32. 32. DDS and SOA Web ServicesFeature Web Services DDSArchitecture Message oriented Middleware Publish subscribe (multicast)Platform Same API is exposed for all HW, Same API is exposed for all HW,Independence OS, and languages supported. OS, and languages supported Browser clients can run anywhereDiscovery of Web server must be specified Dynamic Discovery, no need toendpoints and configured specify where endpoints resideType Safety Use of HTTP and XML does not Strong type safety, application provide strong type safety calls write() and read() with a specific data typeTailoring Limited ability to tailor QoS policies allow for easycommunication communications tailoring of communicationbehavior behaviorsInteroperability Some interoperability with Open standard with proven multiple protocols used: SOAP, interoperability REST, WSDL
    33. 33. For More Information Visit our Website http://www.twinoakscomputing.com for:  Quick Start Guides  Free Evaluations  Free Demonstrations (with source code)  Programmer‟s Guide  Reference Manuals  White Papers Contact Us  Phone: 1-855-671-8754  Email: contact@twinoakscomputing.com  Facebook / Linked In / Twitter / Pinterest / Google+
    34. 34. Summary  Common, Complex Communication Requirements:  Where do I get my data?  How often?  What happens if you don‟t send it?  What happens if I don‟t receive it?  How much received data do I need to store for future use?  How do I select (filter) only the data I need to receive?  CoreDX DDS addresses all these requirements Twin Oaks Computing, Inc34 PROPRIETARY
    35. 35. Questions?

    ×