NDDS The RealTime Publish Subscribe Middleware Network Data

NDDS: The Real-Time Publish Subscribe Middleware Network Data Delivery Service An Efficient Real-Time Application Communications Platform Presented By: Chris Lee

NDDS: Outline Real-Time Data Flow Semantics ➢Communication Architectures ➢The Publish-Subscribe Model ➢The Real-Time Publish-Subscribe Model ➢NDDS Introduction ➢Performance ➢ 11/29/2020 1: 45 2 of 27

Real-Time Data Flow Semantics Understanding Flow Types Critical to RT ➢ ➢ Signals (change constantly) ➢ ➢ ➢ Time-critical: Updates are useless if old. Idempotent: Repeated updates are acceptable. Last-is-best: Latest information is more important than retrying missed samples Commands (sequential instructions) ➢ Status (gives state or goal) ➢ Events (synchronize asynchronous operations) 11/29/2020 1: 45 ➢ Requests (specific request for data) ➢ 3 of 27

Properties of Signals ➢ Rapid in nature ➢ Short persistance ➢ High bandwidth ➢ Most recent value is more important ➢ Example ➢ ➢ Water-level sensor for pumps 11/29/2020 1: 45 4 of 27

Properties of Commands ➢ Delivered in-order ➢ Delivered once and only once ➢ Often not time-critical ➢ Example ➢ ➢ Open a pump valve by 10% 11/29/2020 1: 45 5 of 27

Properties of Status ➢ Usually persists for some time interval ➢ Single delivery is usually not critical ➢ May not be time critical or reliable ➢ Example ➢ ➢ Tank low status 11/29/2020 1: 45 6 of 27

Properties of Request ➢ Could be blocking or non-blocking ➢ Not uniform, each request different ➢ Example ➢ ➢ Request a pumps value setting 11/29/2020 1: 45 7 of 27

Communication Architectures Three Major Architectures ➢ ➢ Client-Server Architectures ➢ ➢ Object Brokers ➢ ➢ All data flows through the server to the clients. Could become bottleneck of communication. Expensive point of failure. Relies on broker to route requests Cumbersome for multi-to-multi communicaitos Little support for deterministic delivery Publish-Subscribe (Next slide) 11/29/2020 1: 45 8 of 27

The Publish-Subscribe Model ➢ Simplifies one-to-many data-distribution ➢ Publishers send data anonymously ➢ Subscribers receive data anonymously ➢ 11/29/2020 1: 45 9 of 27

Publish-Subscribe Advantages Publish-Subscribe are best-suited to distributed applications because. . . ➢ ➢ Applications are modular and scalable ➢ Easy to manage regardsless of scale Data subscribed by name ➢ Easy redundancy* ➢ Efficient bandwidth utilization ➢ Not well suited for. . . ➢ ➢ *When multiple publishers and subscribers can be supported, this allows programs to be replicated and moved transparently. Sporadic request/response traffic 11/29/2020 1: 45 10 of 27

Characteristics of P-S Characteristics of Publish-Subscribe ➢ ➢ Distict declaration and delivery ➢ ➢ ➢ Publisher declares intent to publish. Subscriber declares interest. Publisher sends a publication issue. Named publications ➢ Many-to-many communications support ➢ Event-driven transfer ➢ 11/29/2020 1: 45 11 of 27

PS Middleware The Publish-Subscribe Middleware ➢ Maintains a database that maps publishers to subscribers forming logical data channels ➢ Marshals/Demarshals data from pub to sub ➢ Delivers data when published ➢ Application 11/29/2020 1: 45 Application Programming Publish-subscribe Middleware Operating System Network Interface 12 of 27

Goals of Real Time PS Goals of Real Time Publish-Subscribe ➢ Delivery timing control ➢ Reliability control ➢ Request-reply semantics* ➢ Flexible delivery bandwidth ➢ Fault tolerance** ➢ Selective degradation ➢ Robustness ➢ Dynamic scalability ➢ Efficiency 11/29/2020 1: 45 ➢ * Does not fit will into PS semantics. ** Could Use “hot standby” publishers and subscribers. 13 of 27

The RTPS Model The Real-Time Publish-Subscribe Model ➢ ➢ Extends the PS model for timing-control and client-server communication ➢ ➢ 11/29/2020 1: 45 Publication Parameters Subscription Parameters Reliability and Time-Determinism Client-Server Requests 14 of 27

Publication Parameters ➢ ➢ Four parameters: ➢ ➢ 11/29/2020 1: 45 Topic – label that identifies each data flow. Type – describes the data format. Strength – indicates publisher's weight relative to other publishers of the same topic. Persistence – indicates how long a publication is valid. 15 of 27

Subscription Parameters ➢ ➢ 4 parameters ➢ ➢ Topic & Type (same as publication properties) Minimum separation ➢ ➢ Deadline ➢ 11/29/2020 1: 45 Interval were no new issues are accepted. Max time a subscriber should wait for the next issue. 16 of 27

Reliability and Time-Determinism ➢ Publishers and Subscribers buffer issues ➢ Ensures that subscribers receive issues in the proper sequence ➢ Uses issue sequence numbers ➢ Subscribers request missing issues ➢ Issues removed from buffer when all subscribers receive the issue ➢ 11/29/2020 1: 45 17 of 27

Client-Server Requests ➢ Breaks the PS model; two-way traffic ➢ RTPS makes requests consistant with PS model by implementing requests via a named services. ➢ ➢ ➢ 11/29/2020 1: 45 Has separate data types for request and reply Has best-then-first semantics ( Next Slide ) 18 of 27

Best Then First Semantics ➢ Client specifies a minimum wait and timeout for a reply ➢ Client will choose “strongest” reply received by the first decision time, unless no reply has come in which the client will choose the first reply or timeout. ➢ 11/29/2020 1: 45 19 of 27

NDDS Introduction Network Data Delivery Service ➢ Middleware for distributed, real-time application development ➢ Uses publish-subscribe to: ➢ ➢ 11/29/2020 1: 45 Handle one-to-many and many-to-many data distribution. Meet RT and reliability objective though customizable middleware. Provide application-transparent fault tolerance and system robustness 20 of 27

NDDS Outline ➢ ➢ Architectural Overview ➢ ➢ ➢ Middleware layers Symmetric Design RTPS Enhancements ➢ ➢ ➢ 11/29/2020 1: 45 Patterned subscriptions Customizing reliability requirements Multicast support 21 of 27

NDDS Architectural Overview ➢ ➢ Library ➢ ➢ Database ➢ ➢ Linked into application Keeps information about nodes Tasks ➢ ➢ ➢ 11/29/2020 1: 45 Performs message addressing Marshaling/Demarshaling Transports 22 of 27

Symmetric Design ➢ NDDS maintains a database at each node ➢ Robust: No “special” or “central” nodes that can fail ➢ Nodes can join and leave at any time ➢ 11/29/2020 1: 45 23 of 27

RTPS Enhancements ➢ ➢ Pattern subscriptions ➢ ➢ Customizing reliability requirements ➢ ➢ Allows subscriber to receive a set of related publications without subscribing to each one Reliability vs. Determinism controlled by programmer Multicast support ➢ 11/29/2020 1: 45 Provides flexibility for high bandwidth data (at a cost of latency) 24 of 27

NDDS Performance Latency Total end-to-end delay form publisher to subscriber for different publication issue sizes. Found to be largely independent of packet loss rates. 11/29/2020 1: 45 25 of 27

Maximum Rate and Throughput Maximum issue rate and corresponding publisher-tosubscriber thoughtput for different issue sizes. Heavily dependent on sample size and acceptable packet loss. 11/29/2020 1: 45 26 of 27

References ➢ ➢ ➢ G. Pardo-Castellote, S. Schneider, and M. Hamilton, “NDDS: The Real-Time Publish-Subscriber Middleware”, Real-Time Innovations, Inc. , August 1999. G Parso-Castellote, S. Thiebaut, M. Hamilton, H. Choi, “Real. Time Publish-Subscribe Protocol for Distributed Real-Time Applications”, Real-Time Innovations, Inc. , September 2001. Bob Kindel, “Publish-Subscribe Middleware for Real-Time Applications”, Power. Point presentation, July 2002. http: //www. opengroup. org/boston-jul 02/uploads/ 40_1028305308__qos_bos_real -time_bob_kindel. pdf 11/29/2020 1: 45 27 of 27