Discovery. Details Real-Time Innovations, Inc.

Transcription

1 Discovery Details 2008 Real-Time Innovations, Inc. 1

2 Overview What is discovery? Discovery phases Participant discovery phase Endpoint discovery phase Configuring discovery Tuning discovery Real-Time Innovations, Inc.

3 What is Discovery? Process by which applications using RTI find out about each other DomainParticipants exchange messages about themselves, what they publish and to what they subscribe Happens automatically to begin user-level communications Discovery is Dynamic Newly created apps are found Dead or disconnected apps are dropped Changes are propagated Real-Time Innovations, Inc.

4 Discovery phases Two consecutive phases Participant discovery DomainParticipants discover each other Best-effort Endpoint discovery Participants exchange information about DataWriters and DataReaders Reliable Periodic heartbeat for Participant liveliness Does not happen between Participants in different DDS domains no messages exchanged Real-Time Innovations, Inc.

5 Participant Discovery Participants periodically announce their presence on network Sent to list of initial peers as well as discovered participants Periodic announcement also serves as heartbeat to reassert participant s existence Peer 1 (up) Hello! Hello! Peer 2 (up) Hello! Peer 1 Peer 2 Peer Real-Time Innovations, Inc. Peer 3 (down)

6 Endpoint Discovery Once two Participants discover each other: A reliable session is established Information about each participant s local DataWriters and DataReaders are exchanged Participants end up with internal databases that contain lists of other participants and what each publishes or subscribes Remote endpoints (DW/DR of other participants) are matched with local endpoints Matched for same Topic and compatible QoS Data sent by DataWriters will be delivered by DDS to matched DataReaders Real-Time Innovations, Inc.

7 Discovery Notes Discovery is normally peer-to-peer Optional static discovery module to hardcode discovery information in files Optional server-based discovery service for large scale systems (100 s nodes, 10,000 s endpoints) Discovery never completes Newly created participants need to be discovered Existing participants can be destroyed or otherwise disconnected Applications can create new DataWriters and DataReaders Changes in QoS parameters may be propagated Real-Time Innovations, Inc.

8 Discovery Implementation Discovery data sent using same DDS entities users create to send/receive data Known as built-in DataWriters/DataReaders Always exist in every Participant 3 Topics for Discovery DCPSParticipant Best effort, serves as hello, I m alive message Carries info about Participant DCPSPublication DCPSSubscription Separate topics for DataWriters and DataReaders Reliable Carries writer/reader QOS settings Real-Time Innovations, Inc.

9 Discovery Entities Participant 1 Participant Built-in DataWriter Participant Built-in DataReader Publication Built-in DataWriter Publication Built-in DataReader Subscription Built-in DataWriter Subscription Built-in DataReader Participant Data Msg Publication Data Msg Subscription Data Msg Participant Built-in DataWriter Participant Built-in DataReader Publication Built-in DataWriter Publication Built-in DataReader Subscription Built-in DataWriter Subscription Built-in DataReader Participant 2 Best Effort Reliable Real-Time Innovations, Inc.

10 Eavesdrop on DDS Discovery Using DDSDataReaderListeners, users can listen in on DDS Discovery messages With User or Group Data QoS, user logic can be inserted for authentication/authorization Use ignore_participant(), ignore_publication(), ignore_subscription() APIs to prevent unwanted connections See Chapter 14 Builtin-Topics in Users Manual Real-Time Innovations, Inc.

11 Configuring Discovery Who to talk too List of Initial Peers NDDS_DISCOVERY_PEERS Discovery protocol parameters Discovery QoS Discovery Config QoS Real-Time Innovations, Inc.

12 Initial Peers List of descriptors (addresses) of other participants to say Hello! to Participants on the list do not need not be running Specified using Environment Variable File API Hello! Peer 1 (up) Hello! Peer 2 (up) Hello! Peer 1 Peer 2 Peer Real-Time Innovations, Inc. Peer 3 (down)

13 Contacting Participants DDS DomainParticipants have host-specific transport addresses E.g., for UDPv4, , Unique Participant IDs are automatically assigned to different DomainParticipants running on the same host IDs are integers starting at 0 Only unique within a single DDS domain, may be duplicated across domains Domain 0: Participant (id 0) Participant (id 1) 1 DDS Domain 2 Participants Domain 0: Participant (id 0) Participant (id 1) Participant (id 2) Domain 1: Participant (id 0) 2 DDS Domains 4 Participants Real-Time Innovations, Inc.

14 Peer Descriptors Descriptors combine participant IDs and transport address Specified as a string Used to define Initial-Peer list for Discovery e.g. 4@builtin.udpv4:// #myhost 4@builtin.udpv4://myhost 4@udp4://myhost udpv4://myhost myhost Assuming is the network address of myhost, then all descriptors above are equivalent All specify that there are 5 DomainParticipants with IDs 0-4 on the host myhost with the IP address that should be contacted using the builtin UDPv4 transport Real-Time Innovations, Inc.

15 Peer Descriptor Format Participant Max Transport Try all installed Name that does Almost Use all Network network parts are option, Use Transport but network must Participant Index range (Alias not need transports Class) addresses have either Address address a fully qualified address Address network as ID 0 4 address configured or a transport address fully qualified or a with transport transport transport alias/class address builtin.udpv4 builtin.shmem :// # myhost Separator Separator Separator Real-Time Innovations, Inc.

16 Peer descriptors for Builtin transports UDP on IPv4 updv4:// UDP on IPv6 updv6://0:: Shared Memory (inter-process) shmem:// Descriptors without transport alias will be passed to each transport to see if that transport can send to the address specified by the descriptor Real-Time Innovations, Inc.

17 Multicast addresses as peer descriptors Participants can listen on a multicast address for discovery messages Limited to 1 multicast address for listening Can add multicast addresses to initial-peer list to send discovery messages Can send to multiple multicast addresses Must be valid IPv4 or IPv6 multicast address upv4:// to updv6://ff::, addresses starting with 0xFF Real-Time Innovations, Inc.

18 Default Initial Peers participantqos.discovery.initial_peers builtin.udpv4:// builtin.shmem:// multicast_receive_addresses Notes: shmem not supported on all platforms, e.g. VxWorks Participant Index (ID) range not specified, so by default 0-4 If using multicast, participant index range does not apply, i.e., will find any number of participants running on a host independent of 4@ etc Real-Time Innovations, Inc.

19 How to modify Initial-Peers list 4 options (in order of precedence) 1. API (code) 2. File 3. Environment variable 4. Default values listed previously List is completely replaced by option with highest precedence List is NOT merged from different opotions NDDS_DISCOVERY_PEERS Name of both environment variable as well as file Comma separated list of peer descriptors e.g., NDDS_DISCOVERY_PEERS = ,1@ ,builtin.shmem:// 1 st multicast address in NDDS_DISCOVERY_PEERS will be used as discovery multicast receive address Real-Time Innovations, Inc.

20 Discovery in Large-Scale Systems Systems with > 50 nodes and/or > 50 DomainParticipants may experience Longer times taken for discovery to stabilize upon startup High network traffic caused by discovery messages at startup How to resolve? Can use optional RTI Enterprise Discovery Service, handles 100s of nodes, 1000s of DomainParticipants Configure Discovery peer list to be non-fully meshed asymmetric discovery peers Real-Time Innovations, Inc.

21 Asymmetric Discovery Disable Multicast discovery Otherwise, DomainParticipants will always find all other DomainParticipants Configure Discovery Peers so that only DomainParticipants that need to communicate with each other know about each other At a system level, usually can logically place applications into subgroups that need to communicate with each other Some applications may be in multiple subgroups Set NDDS_DISCOVERY_PEERS to contain only locators of DomainParticipants in the same subgroups Can also use multiple DDS domains (1 per subgroup, some Apps have more than 1 DomainParticipant) However, this is a resource-heavy solution Multiple domains can be useful, but not usually recommended just to solve a large-scale discovery problem Real-Time Innovations, Inc.

22 Asymmetric Discovery Example HMI_1 HMI_2 HMI_125 SERVER_1 SERVER_1 SERVER_ HMIs, 1 Server HMIs only discover the Server HMIs do not discover each other Have to modify the Initial-Peers list of the Server if new HMIs are added/removed SERVER_ Real-Time Innovations, Inc. HMI_1 HMI_2 HMI_125

23 Asymmetric Discovery Example 2 HMI_1 HMI_2 HMI_125 SERVER_1 Discovery multicast receive address: SERVER_1 Discovery multicast receive address: SERVER_1 Discovery multicast receive address: Set the Initial-Peers of the HMIs so that they only contact the Server Do NOT modify the Initial-Peers of the Server Server will add HMIs as unknown peers when contacted. Behavior controlled by DiscoveryQos.accept_unknown_peers SERVER_ Real-Time Innovations, Inc. <use default>

24 Asymmetric Discovery Multicast Example HMI_1 HMI_2 HMI_ HMIs use default discovery multicast receive address, Asymmetric multicast discovery addresses provide simpler deployment configuration management SERVER_ Discovery multicast receive address: Real-Time Innovations, Inc.

25 Tuning Discovery DiscoveryConfigurationQos : participant_liveliness_assert_period <30 seconds> Send out I m alive once every period participant_liveliness_lease_duration <100 seconds> If other participants don t receive a I m alive message within this timeout, then they can consider this participant to be dead initial_participant_announcements <5> Upon startup and finding a new participant, number of I m alive messages to send min/max_participant_announcement_period <1 second> Wait a random time between min and max between sending of the initial I m alive messages. More see documentation Real-Time Innovations, Inc.