1 / 38

Beyond Discovery

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

maggie-brown
Télécharger la présentation

Beyond Discovery

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. BeyondDiscovery Shaun Foley Principal Applications Engineer, RTI

  2. 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?

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

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

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

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

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

  8. Data Types Apps only care about the highest participant index at a given address: add_peer(“2@192.168.44.1”); remove_peer(“2@192.168.44.1”); struct PeerEntry { string addr; //@key ulongpidx; //@key }; struct PeerEntry { string addr; //@key sequence<ulong> pidxs; }; struct PeerEntry { string addr; //@key ulongmax_pidx; }; 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.

  9. Discovery Proxy Initial peers: 0@128 Multicast rxaddrs: empty Address 128 Participant Idx 0 Peer Map – published durably

  10. Discovery Proxy Initial peers: 0@128 Multicast rxaddrs: empty Address 128 Participant Idx 0 Peer Map – published durably 128 1 Application Address 128 Participant Idx 1

  11. Discovery Proxy Initial peers: 0@128 Multicast rxaddrs: empty Address 128 Participant Idx 0 Peer Map – published durably 128 1 Application Address 128 Participant Idx 1 128 2 Application Address 128 Participant Idx 2

  12. Application Discovery Proxy Contact proxy at well-known address Normal application functions 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

  13. Discovery Proxy Initial peers: 0@128 Multicast rxaddrs: empty Address 128 Participant Idx 0 Peer Map – published durably 128 1 Application Address 128 Participant Idx 1 128 2 Application Address 128 Participant Idx 2

  14. Discovery Proxy Initial peers: 0@128 Multicast rxaddrs: empty Address 128 Participant Idx 0 Peer Map – published durably 128 1 Application Address 128 Participant Idx 1 1 0 rtiddsspy 128 2 Application Address 1 Participant Idx 0 Address 128 Participant Idx 2

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

  16. 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

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

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

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

  20. 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 = ... DW B roid 2 DR B roid4 DW A roid 1 Participant X DR A roid 3 Participant Y X Look up participant by name “X” Assert X’s endpoints into discovery database A B Discovery data: QoS, Type description, … User samples

  21. 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

  22. 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 = ... DW B roid20 DR B roid4 DW A roid10 Participant X DR A roid 3 Participant Y X Look up participant by name “X” Assert X’s endpoints into discovery database A X B Who is ROID 10 and 20??? Discovery data: QoS, Type description, … User samples

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

  24. 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

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

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

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

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

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

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

  31. 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?

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

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

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

  35. “Inherit, not to reuse, but to be reused”1 • 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 • 1: Sutter and Alexandrescu, C++ Coding Standards

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

  37. Fin

More Related