|
| 1 | +.. include:: ../../../03-exports/aliases.include |
| 2 | +.. include:: ../../../03-exports/aliases-api.include |
| 3 | +.. include:: ../../../03-exports/roles.include |
| 4 | + |
| 5 | +.. _freq_discovery_questions: |
| 6 | + |
| 7 | +Discovery Frequently Asked Questions |
| 8 | +==================================== |
| 9 | + |
| 10 | +.. collapse:: What are the two main phases involved in the discovery process of Fast DDS? |
| 11 | + |
| 12 | + |br| The two main phases involved in the discovery process of Fast DDS are the Participant Discovery Phase (PDP) and the Endpoint Discovery Phase (EDP). |
| 13 | + The Participant Discovery Phase (PDP) involves |DomainParticipants-api| recognizing each other by sending periodic announcement messages with their unicast addresses. |
| 14 | + Matching occurs when they are in the same DDS Domain, using multicast by default, though unicast and announcement frequency can be customized. |
| 15 | + In the Endpoint Discovery Phase (EDP), DataWriters and DataReaders acknowledge each other by sharing information about topics and data types over the established channels. |
| 16 | + Matching endpoints with the same topic and data type are then ready to exchange user data. |
| 17 | + For further information, refer to :ref:`disc_phases`. |
| 18 | + |
| 19 | +---------- |
| 20 | + |
| 21 | +.. collapse:: What discovery mechanisms does FastDDS provide? |
| 22 | + |
| 23 | + |br| There are four discovery mechanisms in DDS: Simple Discovery, which follows the RTPS standard for both PDP and EDP, ensuring compatibility with other DDS implementations; Static Discovery, which uses the Simple Participant Discovery Protocol (SPDP) but skips the Endpoint Discovery phase if endpoint details are pre-known; Discovery Server, which employs a centralized server for meta traffic discovery; and Manual Discovery, which disables the PDP and requires users to manually match RTPS participants and endpoints using external meta-information channels. |
| 24 | + For further information, refer to :ref:`disc_mechanisms`. |
| 25 | + |
| 26 | +---------- |
| 27 | + |
| 28 | +.. collapse:: How can you improve the chances of successful participant discovery when using the SIMPLE discovery protocol, and what role do initial announcements play in this process? |
| 29 | + |
| 30 | + |br| To improve the chances of successful participant discovery when using the SIMPLE discovery protocol, you can configure initial announcements to send multiple discovery messages at short intervals. |
| 31 | + This increases the likelihood that DomainParticipants will detect each other despite potential network disruptions or message loss. |
| 32 | + By adjusting the |InitialAnnouncementConfig::count-api| (number of announcements) and |InitialAnnouncementConfig::period-api| (interval between announcements), you can optimize discovery reliability during startup. |
| 33 | + For further information, refer to :ref:`simple_disc_settings`. |
| 34 | + |
| 35 | +---------- |
| 36 | + |
| 37 | +.. collapse:: What is an initial peer list? |
| 38 | + |
| 39 | + |br| An initial peer list contains one or more IP-port address pairs corresponding to remote DomainParticipants PDP discovery listening resources, so that the local DomainParticipant will not only send its PDP traffic to the default multicast address-port specified by its domain, but also to all the IP-port address pairs specified in the initial peers list. |
| 40 | + For further information, refer to :ref:`simple_disc_settings`. |
| 41 | + |
| 42 | +---------- |
| 43 | + |
| 44 | +.. collapse:: When could a static configuration of peers be used? |
| 45 | + |
| 46 | + |br| When all DataWriters and DataReaders, and their Topics and data types, are known beforehand, the EDP phase can be replaced with a static configuration of peers. |
| 47 | + For further information, refer to :ref:`discovery_static`. |
| 48 | + |
| 49 | +---------- |
| 50 | + |
| 51 | +.. collapse:: What is the primary difference between the Discovery Server mechanism and Simple discovery mechanism in terms of managing metatraffic? |
| 52 | + |
| 53 | + |br| The Discovery Server mechanism is based on a client-server discovery paradigm, the metatraffic is managed by one or several server DomainParticipants, as opposed to simple discovery, where metatraffic is exchanged using a message broadcast mechanism like an IP multicast protocol. |
| 54 | + For further information, refer to :ref:`discovery_server`. |
| 55 | + |
| 56 | +---------- |
| 57 | + |
| 58 | +.. collapse:: What is the primary function of a Discovery Server in the DDS architecture? |
| 59 | + |
| 60 | + |br| The primary function of a Discovery Server in the DDS architecture is to centralize and redistribute discovery information among DomainParticipants, ensuring efficient communication between clients and servers. |
| 61 | + The server collects discovery data from clients (and other servers) and redistributes it to relevant participants, running a "matching" algorithm to provide only the necessary information for DataWriters and DataReaders to establish communication. |
| 62 | + It also facilitates server-to-server connections, enabling a more scalable discovery process across the network. |
| 63 | + For further information, refer to :ref:`discovery_server`. |
| 64 | + |
| 65 | +---------- |
| 66 | + |
| 67 | +.. collapse:: What is the primary purpose of a "BACKUP" server in the Discovery Server mechanism? |
| 68 | + |
| 69 | + |br| A ``BACKUP`` server is a server that persists its discovery database into a file. |
| 70 | + This type of server can load the network graph from a file on start-up without the need of receiving any client's information. |
| 71 | + For further information, refer to :ref:`discovery_server`. |
| 72 | + |
| 73 | +---------- |
| 74 | + |
| 75 | +.. collapse:: What is a client in this context? |
| 76 | + |
| 77 | + |br| A ``CLIENT`` is a participant that connects to one or more servers from which it receives only the discovery information they require to establish communication with matching endpoints. |
| 78 | + For further information, refer to :ref:`discovery_server`. |
| 79 | + |
| 80 | +---------- |
| 81 | + |
| 82 | +.. collapse:: What is the difference between a CLIENT and a SUPER_CLIENT? |
| 83 | + |
| 84 | + |br| A ``SUPER_CLIENT`` is a client that receives the discovery information known by the server, in opposition to clients, which only receive the information they need. |
| 85 | + For further information, refer to :ref:`discovery_server`. |
| 86 | + |
| 87 | +---------- |
| 88 | + |
| 89 | +.. collapse:: What is the purpose of each server specifying its own locator list in the context of discovery configuration? |
| 90 | + |
| 91 | + |br| Each client must keep a list of locators associated to the servers to which it wants to link. |
| 92 | + Each server specifies its own locator list which must be populated with ``RemoteServerAttributes`` objects with a valid ``metatrafficUnicastLocatorList`` or ``metatrafficMulticastLocatorList``. |
| 93 | + In XML the server list and its elements are simultaneously specified. |
| 94 | + For further information, refer to :ref:`discovery_server`. |
| 95 | + |
| 96 | +---------- |
| 97 | + |
| 98 | +.. collapse:: What is the typical interval of time between discovery messages sent by clients to servers, as described in the text? |
| 99 | + |
| 100 | + |br| As explained above the clients send discovery messages to the servers at regular intervals (ping period) until they receive message reception acknowledgement. |
| 101 | + The default value for this period is 450 ms. |
| 102 | + For further information, refer to :ref:`discovery_server`. |
| 103 | + |
| 104 | +| |
0 commit comments