Best Practices Using RTI Connext DDS


Published on

View On-Demand

Repeat Success, Not Mistakes; Use DDS Best Practices to Design Your Complex Distributed Systems

RTI Connext DDS is a powerful tool that lets you efficiently build and integrate complex distributed systems like no other technology – if you use it right. Be aware of how to get the most out of DDS and how to avoid common pitfalls when developing your system. We've developed RTI Connext best practices over the course of hundreds of customer projects and many years. In this webinar, you will learn how to apply the best practices we have developed to use RTI Connext DDS in ways that will enable your system to scale effectively with optimal performance, while avoiding missteps that will cause poor performance, non-determinism and scalability problems.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Best Practices Using RTI Connext DDS

  1. 1. Your systems. Working as one. Best Practices using RTI Connext DDS Rose Wahlin Principal Software Engineer
  2. 2. Best Practices • Introduction • Types of best practices – Architectural – Application design and implementation – Network and QoS configuration • Where to find more information
  3. 3. Introduction • Best practices guide you in building a system that is – Future-proof – Scalable – High performance – Testable • Without best practices, may be building suboptimal systems – Lose time figuring out best approach – System quality suffers
  4. 4. Categories • Architectural – Creating a network data model that meets your requirements • Application design and implementation – Making optimal design decisions within a single application • Network configuration and QoS – Tuning for your system requirements
  5. 5. Create a Network Data Model • Determine the structure of the data you will send over the network based on – The state you want to represent – The delivery characteristics of the data • For example: – Representing state data for a fleet of trucks – Trucks have license plate numbers, position, oil levels, maintenance information – These change at different rates, or aperiodically • This can map to Topics: – TruckGPS, TruckOilLevel, and TruckMaintenance
  6. 6. Use Typed Data Give your data a type instead of sending binary • Middleware handles endianness • Automatically plug in applications – Data visualization and debugging (Excel, RTI DDS Spy) – Data recording, replay, and database integration (RTI Recorder, RTI Replay, Real-Time Connect) – Mediation and transformation (RTI Routing Service) • RTI Connext DDS can filter data based on the content • Encourages good design with discrete updates
  7. 7. Use Keyed Data Represent data-objects within the middleware • Keying data tells Connext DDS about unique data- objects – or instances – inside your Topics – Example: VIN is the unique ID of a truck, and maps to a key field in all data types representing trucks • Connext notifies you about instance lifecycle – New instance, instance alive, instance not alive • Connext can have behavior per-instance – Notifications of delayed instance updates – Cache allocated per-instance – Failure/failover mechanisms per-instance
  8. 8. Use Keyed Data (Example) Represent data-objects within the middleware struct TruckGPS { string<18> VIN; //@key LatLong position; long speed; long direction; }; Key Name Type VIN string position LatLong speed long direction long
  9. 9. Create Few DomainParticipants Create the minimum number of DomainParticipants required by your data model • DomainParticipant objects are responsible for: – Discovering Entities in the domain – Maintaining a discovery database – Creating threads • It is not necessary to create one DomainParticipant per DataWriter or DataReader in an application – Doing this uses unnecessary local resources (threads, sockets, memory) – Because of discovery, this also uses unnecessary remote resources (network bandwidth, memory) • An application typically creates one DomainParticipant per domain it wants to join
  10. 10. Create Entities Early Do not create DataWriters and DataReaders just before sending or receiving • When you create a DataWriter or DataReader, Connext: – Allocates the queues for that Entity – Sends discovery messages notifying other applications about that Entity • Discovery process matches DataReaders and DataWriters over the network • With default QoS, DataReaders receive data only after discovery is complete • Better to create entities early so discovery has time to complete
  11. 11. Never Block a Callback Blocking callbacks causes non-deterministic pain • Listener callbacks are called from Connext threads that may do various tasks – Receive data for one or more DataReaders – Send and receive reliability metadata for one or more DataWriters – Handle periodic events such as deadlines and liveliness • Blocking these callbacks will prevent the middleware from working correctly – May not receive expected data on one or more DataReaders – May fail to notify other applications of liveliness • If you are creating a layer above Connext DDS, be careful about exposing callbacks to your users
  12. 12. Use WaitSets, Not Listeners Unless you need extreme performance, WaitSets are safer • Listeners receive data in the middleware threads – Lowest latency receive of data – Blocking is a problem • WaitSets receive data in a user thread – Can do long processing, block, call all Connext APIs – Slight increase in latency due to thread context switch
  13. 13. Use the Right Reliability Decoupling protocol and data definition allows you to specify different reliability per-channel • If your data is modeled as discrete updates to object state, you often do not need strict reliability – Example: “I need the current state of this turbine rotor, and the previous state.” • Strict reliability requires higher overhead to store and deliver all data • Choose reliability level depending on your requirements instead of defaulting to strict reliability: – Strict reliability: DataWriter is not allowed to overwrite data if existing DataReaders have not received it. – Non-strict reliability: DataWriter keeps the last N data samples to reliably deliver to DataReaders. Is allowed to overwrite samples even if DataReaders have not received it. – Best effort: DataWriters do not keep a queue of data for DataReaders and make no guarantees of delivery
  14. 14. Use the Maximum Transport Sizes Larger transport sizes increase throughput (up to a point) • Transports have different max data sizes – UDPv4 supports data sizes of 65507 on most platforms (64K – overhead) – TCP and shared memory support higher • Choose the highest reasonable value supported by all transports • Reasonable is determined by: – Memory usage – OS limitations – Bandwidth limitations
  15. 15. Use Multicast for One-to-Many You can get significant increases in one-to-many throughput with multicast • Advantages: – Increased throughput – on DataReaders similar throughput to one-to-one – Significant reduction of CPU load on DataWriter • Disadvantages: – If DataWriter is reliable, may need to tune reliability to avoid ACK storms – Some switches block bursts of multicast traffic • Note that multicast is not required for Connext DDS
  16. 16. Configure Switches for IGMP Snooping If switches can snoop multicast traffic, they can filter data in hardware • Typical applications use multicast for discovery • May also use multicast for user data • By default, Layer 2 devices treat IP multicast as broadcast traffic – Subscribers receive all the data, and must filter • Enabling IGMP snooping can increase scalability of discovery and multicast user data
  17. 17. Tune Your OS for Throughput Linux and Windows can be tuned for better throughput than out of the box • Most OSes are not configured for high throughput – Neither Linux nor Windows have ideal throughput out of the box – Embedded systems are often tuned for small footprint rather than high-throughput • You can increase throughput by configuring: – The Windows registry – Sysctl.conf – Settings specific to your embedded platform • Details can be found in RTI’s Community Portal Knowledge Base: –
  18. 18. More Information • Go to: – –
  19. 19. Your systems. Working as one. Download Connext Free Trial NOW