1. Twin Oaks Computing, Inc.
CoreDX DDS
Technical Brief
Jul 2012

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. 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 Subscriber
Publisher Topic
Subscriber
Data Type QoS

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. 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. Technical Features
Dynamic Discovery Cross-platform
Reliability Interoperability
Durability Portability
Historical Data Caches High Performance
Filtering Highly Configurable
Ownership

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. 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. 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. 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. 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. 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. 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. CoreDX DDS Features:
Durability: Example
 Durability Example
Data
Producer
S1 S3 Data published with
Durability = TRANSIENT_LOCAL
S2 S4
Subscribing to data with Subscribing to data with S4 S2
Durability = VOLITILE Durability =
S4 TRANSIENT_LOCAL S2 S1
Data Data
Consumer 1 Consumer 2

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. 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. 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. 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. 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. 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. 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. 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, Inc
22 PROPRIETARY

23. CoreDX DDS:
Performance: Throughput, Latency
No Performance Sacrifice
Performance Summary:
• Throughput > 900 Mbps
• Latency < 70 usec
Twin Oaks Computing, Inc
23 PROPRIETARY

24. CoreDX DDS:
Performance: CPU, Network
Long 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, Inc
24 PROPRIETARY

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, Inc
25 PROPRIETARY

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, Inc
26 PROPRIETARY

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. Comparisons
DDS
JMS
Web Services
XMPP

29. Comparison:
DDS and JMS
lookup ConnectionFactory JNDI lookup ConnectionFactory
create Connection create Connection
create Session create Session
create MessageProducer JMS create MessageConsumer
start the Connection Server start the Connection
write data read data
JMS requires a Server that must JMS Server often requires
be configured and connected significant resources, and creates
a single point of failure
create a DDS Participant
create a Topic create a DDS participant
create a Publisher create a Topic
create a DataWriter create a Subscriber
write data create a DataReader
Each DDS application contains all read data
necessary code for discovery and
communications, no server
required

30. DDS and JMS
Feature JMS DDS
Architecture 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 supported
Discovery of JNDI and JMS servers must be Dynamic Discovery, no need to
endpoints specified and configured specify where endpoints reside
Type Safety Generic Objects and XML are Strong type safety, application
not type safe calls write() and read() with a
specific data type
Tailoring Limited ability to tailor QoS policies allow for easy
communication communications tailoring of communication
behavior behaviors
Interoperability None Open standard with proven
interoperability

31. Comparison:
DDS and SOA Web Services
Web Server
create Service
enable web services configure Server Address
install web service Web call Service
Service get response
A web server must be configured The client must be configured with
to provide web services, and the the address of the web server
web service must be installed before the service can be called
create a DDS Participant create a DDS participant
create a Topic create a Topic
create a Publisher create a Subscriber
create a DataWriter create a DataReader
write data read data
Each DDS application contains all
necessary code for discovery and
communications, no server or
end point configuration required

32. DDS and SOA Web Services
Feature Web Services DDS
Architecture 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
anywhere
Discovery of Web server must be specified Dynamic Discovery, no need to
endpoints and configured specify where endpoints reside
Type Safety Use of HTTP and XML does not Strong type safety, application
provide strong type safety calls write() and read() with a
specific data type
Tailoring Limited ability to tailor QoS policies allow for easy
communication communications tailoring of communication
behavior behaviors
Interoperability Some interoperability with Open standard with proven
multiple protocols used: SOAP, interoperability
REST, WSDL

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. 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, Inc
34 PROPRIETARY

35. Questions?