Best Practices Using RTI Connext DDS
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share

Best Practices Using RTI Connext DDS

  • 1,696 views
Uploaded on

View On-Demand http://ecast.opensystemsmedia.com/403 ...

View On-Demand http://ecast.opensystemsmedia.com/403

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,696
On Slideshare
1,696
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
34
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Your systems. Working as one. Best Practices using RTI Connext DDS Rose Wahlin Principal Software Engineer
  • 2. Best Practices • Introduction • Types of best practices – Architectural – Application design and implementation – Network and QoS configuration • Where to find more information
  • 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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: – Community.rti.com/kb
  • 18. More Information • Go to: – community.rti.com/best-practices – community.rti.com/forum
  • 19. Your systems. Working as one. Download Connext Free Trial NOW www.rti.com/downloads