Beyond Discovery Shaun Foley Principal Applications Engineer, RTI

Topics Unicast Discovery – How can applications discover each other when multicast is unavailable or undesirable? Static Endpoint Discovery – How can I minimize the configuration burden when using RTI Limited Bandwidth Static Discovery Plugins? User Discovery – How does DDS discovery fit into the broader picture of system architecture?

Topics Unicast Discovery – How can applications discover each other when multicast is unavailable or undesirable? Static Endpoint Discovery User Discovery

Tell Nathan I am in room 205 Angela Hotel Reception Track guests and room numbers. Nathan Where is Angela? Communication established: decide where to meet for beer Angela : room 205 Call room 205

Tell everyone I am address 205 Application A Discovery Proxy A: 205 B: 408 … Application B Where is everyone? Contact 205 Contact 202 Contact 408 … Communication established: Begin app biz-logic Track applications and addresses

Tell everyone I am address 205 Application A Discovery Proxy A: 205 B: 408 … Application B Where is everyone? Contact 205 Contact 202 Contact 408 … Track applications and addresses Contact proxy at well-known address Communication established: Begin app biz-logic Contact proxy at well-known address Call add_peer() on received addresses

athena Domain Participant 0 Domain Participant 1 Domain Participant 2 Domain Participant 3 Domain Participant 4 Remote Participant peer list: peer list: discovery announcements An Implementation Aside: Peer Indices and Addresses

struct PeerEntry { string addr; ulong pidx; }; struct PeerEntry { string addr; sequence pidxs; }; struct PeerEntry { string addr; ulong max_pidx; }; Data Types Publishes unneeded data. Resource limits depend on # of expected DPs on node. Must choose arbitrary sequence bound. Last value cache. Relies on idempotent add_peer(). Only removes peer when last DP on machine dies. Apps only care about the highest participant index at a given address:

Discovery Proxy Address 128 Participant Idx 0 Peer Map – published durably Initial peers: Multicast rx addrs: empty Addr PIdx

Application Discovery Proxy Address 128 Participant Idx 1 Address 128 Participant Idx 0 Peer Map – published durably Initial peers: Multicast rx addrs: empty Addr128 PIdx1

Application Discovery Proxy Address 128 Participant Idx 1 Application Address 128 Participant Idx 2 Address 128 Participant Idx 0 Peer Map – published durably Initial peers: Multicast rx addrs: empty Addr128 PIdx12

Application Discovery Proxy Normal application functions Contact proxy at well- known address When proxy tells us about new applications, call add_peer() proxy_client.h Three lines of code to change normal application to use unicast discovery proxy

Application Discovery Proxy Address 128 Participant Idx 1 Application Address 128 Participant Idx 2 Address 128 Participant Idx 0 Peer Map – published durably Initial peers: Multicast rx addrs: empty Addr128 PIdx12

Application Discovery Proxy Address 128 Participant Idx 1 Application Address 128 Participant Idx 2 rtiddsspy Address 1 Participant Idx 0 Address 128 Participant Idx 0 Peer Map – published durably Initial peers: Multicast rx addrs: empty Addr128 1 PIdx120

Topics Unicast Discovery Static Endpoint Discovery – How can I minimize the configuration burden when using RTI Limited Bandwidth Static Discovery Plugins? User Discovery

Why Static Discovery? Unicast Discovery Static Endpoint Discovery – How can I minimize the configuration burden when using RTI Limited Bandwidth Static Discovery Plugins? User Discovery

A Participant A sends to initial peers Participant B responds B ~400 bytes, but varies from… -Propagated properties -Entity name -# of Locators R W Exchange DW/DR info Participant A Participant B ~800 bytes, but varies from… -Propagated properties -Entity name -Type description Participant Announcement Endpoint Announcement Why Static Discovery?

Federation with Routing Service Routing Service Fully meshed discovery within cluster Routing Service Routing Services act as gateways for cluster May be difficult to choose meaningful clusters All cross-cluster traffic passes through Routing Services

A Participant A sends to initial peers Participant B responds B Participant A Participant B Endpoint Discovery with Limited Bandwidth Plugins Read LBED configuration to learn about remote participant’s datareaders and datawriters R R W No endpoint data sent on the wire!

Participant X DW A roid 1 DW A roid 1 X X DW B roid 2 DW B roid 2 LBED Configuration participant name = “Y” reader rtps_object_id = 3 topic_name = A qos =... reader rtps_object_id = 4 topic_name = B qos =... participant name = “X” writer rtps_object_id = 1 topic_name = A qos =... writer rtps_object_id = 2 topic_name = B qos =... Participant Y DR A roid 3 DR A roid 3 DR B roid 4 DR B roid 4 Look up participant by name “X” B B A A Assert X’s endpoints into discovery database Discovery data: QoS, Type description, … User samples

Configuration Challenges Applications do not use the LBED configuration to create DDS entities Actual configuration and LBED configuration must remain synchronized DDS relies on each datawriter or datareader to have a unique object ID Object ID assignment must be deterministic – If created serially: maintain DW/DR count – If created in parallel: hash topic name

Participant X DW A roid 10 DW A roid 10 X X DW B roid 20 DW B roid 20 LBED Misconfiguration participant name = “Y” reader rtps_object_id = 3 topic_name = A qos =... reader rtps_object_id = 4 topic_name = B qos =... participant name = “X” writer rtps_object_id = 1 topic_name = A qos =... writer rtps_object_id = 2 topic_name = B qos =... Participant Y DR A roid 3 DR A roid 3 DR B roid 4 DR B roid 4 Look up participant by name “X” B B A A Assert X’s endpoints into discovery database Discovery data: QoS, Type description, … User samples Who is ROID 10 and 20??? X

Participant X Discovery Monitor Endpoint A X X Endpoint B Participant Y Endpoint C Endpoint D Y Y Collect Builtin Topic data and save to XML file B B A A C C D D Discovery data: QoS, Type description, … Generating LBED Configuration

Two Steps to Use LBED Configuration Tell applications to use load LB plugins Select previously generated LBED configuration These can be set in participant QoS section via XML

Topics Unicast Discovery Static Endpoint Discovery User Discovery – How does DDS discovery fit into the broader picture of system architecture?

Selective Discovery DDS participants communicate with and store data about all endpoints, even those they do not match. How can we avoid this?

Participant X Discovery Proxy Endpoint A X X User data Discovery metadata: Address, DP index, Topic name, … Discovery data: QoS, Type description, … C C Endpoint B Participant Y Endpoint C Endpoint D Y Y B B A A Y Y X X Y Y D D process data process metadata Proxied Participant Location normal communication X X

Participant X Discovery Proxy Endpoint A X X Endpoint B Participant Y Endpoint C Endpoint D f(A,B) Y Y process data process metadata Proxied Topic Data - no match scenario B B A A C C D D f(C,D) User data Discovery metadata: Address, DP index, Topic name, … Discovery data: QoS, Type description, … X X Y Y

Participant X Discovery Proxy Endpoint A X X Endpoint B Participant Y Endpoint C Endpoint D f(A,B) Y Y process data process metadata Proxied Topic Data - match scenario B B A A C C D D f(C,D) normal communication User data Discovery metadata: Address, DP index, Topic name, … Discovery data: QoS, Type description, … A A C C X X Y Y

Participant X Discovery Proxy Endpoint A X X Endpoint B Participant Y Endpoint C Endpoint D Y Y X X Y Y process data process metadata B B A A C C D D normal communication User data Discovery metadata: Address, DP index, Topic name, … Discovery data: QoS, Type description, … A A B B A A Control Data

Discovery Control Control information need not be distributed the same way as data – LBED plugin uses files to describe endpoints, DDS to communicate – WSDL to describe services, SOAP to communicate – DNS to find, {HTTP, DDS, … } to communicate How can we maximize control plane flexibility?

Discovery Data Fixed data type – Necessary for DDS interoperability Uses [internal] DDS writers and readers Has associated QoS Participant Built-in Data Reader Publication Built-in Data Writer Subscription Built-in Data Reader Participant Built-in Data Writer Subscription Built-in Data Writer Publication Built-in Data Reader Participant Built-in Data Reader Publication Built-in Data Writer Subscription Built-in Data Reader Participant Built-in Data Writer Subscription Built-in Data Writer Publication Built-in Data Reader Best EffortReliable

Application participant Plugin Userdisc Plugin participant Publication DataWriter Publication DataWriter Subscription DataWriter Publication DataReader Publication DataReader Subscription DataReader Discovery database Bridging Discovery Data to Normal DDS Topics

Application participant Hello Writer Plugin Userdisc Plugin participant Publication DataWriter Publication DataWriter Subscription DataWriter Publication DataReader Publication DataReader Subscription DataReader core calls… afterLocalWriterEnabled Topic: “Hello” key participant_key... Topic: “Hello” key participant_key... Topic: “Hello” key participant_key... Topic: “Hello” key participant_key... call into core… assertRemoteReader

Routing Service – System federation and bridging – Interacting with non-DDS data – Mediation and transformation Recording and Replay Services Persistence Service – Implement DDS durability – Build more complex messagine on top of DDS User code – Infrastructure frameworks, programmer familiarity “Inherit, not to reuse, but to be reused” 1 1: Sutter and Alexandrescu, C++ Coding Standards

Endpoint Description Key Topic name Type name QoS Type description Does not change for static discovery Unused by 95% of applications Endpoint Header Key Topic name Type name Endpoint QoS Key QoS reference or data Endpoint Type Key Type description Published separately Accessible via pub-sub or request-reply Easily reconstructed on other side Today’s way The Right Way

Fin