# 13.1.3. Discovery Server¶

During Discovery, the Participant Discovery Phase (PDP) relies on meta traffic announcements sent to multicast addresses so that all the DomainParticipants in the network can acknowledge each other. This phase is followed by a Endpoint Discovery Phase (EDP) where all the DomainParticipants use discovered unicast addresses to exchange information about their Publisher and Subscriber entities with the rest of the DomainParticipants, so that matching between entities of the same topic can occur.

Fast DDS provides a client-server discovery mechanism, in which a server DomainParticipant operates as the central point of communication. It collects and processes the metatraffic sent by the client DomainParticipants, and then distributes the appropriate information among the rest of the clients.

A complete description of the feature can be found at Discovery Server Settings. The following subsections present configurations for different discovery server use cases.

## 13.1.3.1. UDPv4 basic example setup¶

To configure the Discovery Server scenario, two types of participants are created: the server participant and the client participant. Two parameters to be configured in this type of implementation are outlined:

• Server GUID Prefix: This is the unique identifier of the server.

• Server Address-port pair: Specifies the IP address and port of the machine that implements the server. Any free random port can be used. However, using RTPS standard ports is discouraged.

SERVER

C++

DomainParticipantQos qos;

// Configure the current participant as SERVER
qos.wire_protocol().builtin.discovery_config.discoveryProtocol = DiscoveryProtocol_t::SERVER;

// Define the listening locator to be on interface 192.168.10.57 and port 56542
Locator_t server_locator;
IPLocator::setIPv4(server_locator, "192.168.10.57");
server_locator.port = 56542;
qos.wire_protocol().builtin.metatrafficUnicastLocatorList.push_back(server_locator);

// Set the GUID prefix to identify this server
std::istringstream("72.61.73.70.66.61.72.6d.74.65.73.74") >> qos.wire_protocol().prefix;


XML

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<participant profile_name="UDP SERVER" is_default_profile="true">
<rtps>
<builtin>
<discovery_config>
<discoveryProtocol>SERVER</discoveryProtocol>
</discovery_config>
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<port>56542</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</builtin>
<prefix>72.61.73.70.66.61.72.6d.74.65.73.74</prefix>
</rtps>
</participant>
</profiles>


CLIENT

C++

DomainParticipantQos qos;

// Configure the current participant as CLIENT
qos.wire_protocol().builtin.discovery_config.discoveryProtocol = DiscoveryProtocol_t::CLIENT;

// Define a locator for the SERVER Participant on address 192.168.10.57 and port 56542
Locator_t remote_server_locator;
IPLocator::setIPv4(remote_server_locator, "192.168.10.57");
remote_server_locator.port = 56542;

RemoteServerAttributes remote_server_attr;
remote_server_attr.metatrafficUnicastLocatorList.push_back(remote_server_locator);

// Set the GUID prefix to identify the remote server

// Connect to the SERVER at the previous locator
qos.wire_protocol().builtin.discovery_config.m_DiscoveryServers.push_back(remote_server_attr);


XML

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<participant profile_name="UDP CLIENT" is_default_profile="true">
<rtps>
<builtin>
<discovery_config>
<discoveryProtocol>CLIENT</discoveryProtocol>
<discoveryServersList>
<RemoteServer prefix="72.61.73.70.66.61.72.6d.74.65.73.74">
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<port>56542</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</RemoteServer>
</discoveryServersList>
</discovery_config>
</builtin>
</rtps>
</participant>
</profiles>


## 13.1.3.2. UDPv4 redundancy example¶

The basic setup example presents a single point of failure. That is, if the server fails the clients are not able to perform the discovery. To prevent this, several servers could be linked to each client. Then, a discovery failure only takes place if all servers fail, which is a more unlikely event.

In the example below, the values have been chosen to ensure each server has a unique GUID Prefix and unicast address-port pair. Note that several servers can share the same IP address but their port numbers should be different. Likewise, several servers can share the same port if their IP addresses are different.

Prefix

75.63.2D.73.76.72.63.6C.6E.74.2D.31

192.168.10.57:56542

75.63.2D.73.76.72.63.6C.6E.74.2D.32

192.168.10.60:56543

SERVER

C++

// Configure first server's locator on interface 192.168.10.57 and port 56542
Locator_t server_locator_1;
IPLocator::setIPv4(server_locator_1, "192.168.10.57");
server_locator_1.port = 56542;

// Configure participant_1 as SERVER listening on the previous locator
DomainParticipantQos server_1_qos;
server_1_qos.wire_protocol().builtin.discovery_config.discoveryProtocol = DiscoveryProtocol_t::SERVER;
std::istringstream("75.63.2D.73.76.72.63.6C.6E.74.2D.31") >> server_1_qos.wire_protocol().prefix;
server_1_qos.wire_protocol().builtin.metatrafficUnicastLocatorList.push_back(server_locator_1);

// Configure second server's locator on interface 192.168.10.60 and port 56543
Locator_t server_locator_2;
IPLocator::setIPv4(server_locator_2, "192.168.10.60");
server_locator_2.port = 56543;

// Configure participant_2 as SERVER listening on the previous locator
DomainParticipantQos server_2_qos;
server_2_qos.wire_protocol().builtin.discovery_config.discoveryProtocol = DiscoveryProtocol_t::SERVER;
std::istringstream("75.63.2D.73.76.72.63.6C.6E.74.2D.32") >> server_2_qos.wire_protocol().prefix;
server_2_qos.wire_protocol().builtin.metatrafficUnicastLocatorList.push_back(server_locator_2);


XML

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<participant profile_name="UDP SERVER 1">
<rtps>
<prefix>75.63.2D.73.76.72.63.6C.6E.74.2D.31</prefix>
<builtin>
<discovery_config>
<discoveryProtocol>SERVER</discoveryProtocol>
</discovery_config>
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<port>56542</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</builtin>
</rtps>
</participant>

<participant profile_name="UDP SERVER 2">
<rtps>
<prefix>75.63.2D.73.76.72.63.6C.6E.74.2D.32</prefix>
<builtin>
<discovery_config>
<discoveryProtocol>SERVER</discoveryProtocol>
</discovery_config>
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<port>56543</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</builtin>
</rtps>
</participant>
</profiles>


CLIENT

C++

// Define a locator for the first SERVER Participant
Locator_t remote_server_locator_1;
IPLocator::setIPv4(remote_server_locator_1, "192.168.10.57");
remote_server_locator_1.port = 56542;

RemoteServerAttributes remote_server_attr_1;
remote_server_attr_1.metatrafficUnicastLocatorList.push_back(remote_server_locator_1);

// Define a locator for the second SERVER Participant
Locator_t remote_server_locator_2;
IPLocator::setIPv4(remote_server_locator_2, "192.168.10.60");
remote_server_locator_2.port = 56543;

RemoteServerAttributes remote_server_attr_2;
remote_server_attr_2.metatrafficUnicastLocatorList.push_back(remote_server_locator_2);

// Configure the current participant as CLIENT connecting to the SERVERS at the previous locators
DomainParticipantQos client_qos;
client_qos.wire_protocol().builtin.discovery_config.discoveryProtocol = DiscoveryProtocol_t::CLIENT;
client_qos.wire_protocol().builtin.discovery_config.m_DiscoveryServers.push_back(remote_server_attr_1);
client_qos.wire_protocol().builtin.discovery_config.m_DiscoveryServers.push_back(remote_server_attr_2);


XML

<?xml version="1.0" encoding="UTF-8" ?>
<profiles xmlns="http://www.eprosima.com/XMLSchemas/fastRTPS_Profiles">
<participant profile_name="UDP CLIENT REDUNDANCY">
<rtps>
<builtin>
<discovery_config>
<discoveryProtocol>CLIENT</discoveryProtocol>
<discoveryServersList>
<RemoteServer prefix="75.63.2D.73.76.72.63.6C.6E.74.2D.31">
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<port>56542</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</RemoteServer>
<RemoteServer prefix="75.63.2D.73.76.72.63.6C.6E.74.2D.32">
<metatrafficUnicastLocatorList>
<locator>
<udpv4>
<port>56543</port>
</udpv4>
</locator>
</metatrafficUnicastLocatorList>
</RemoteServer>
</discoveryServersList>
</discovery_config>
</builtin>
</rtps>
</participant>
</profiles>


## 13.1.3.3. UDPv4 persistency example¶

On Discovery Server, servers gather and maintain the information of all connected endpoints, and distribute it to the clients. In case of a server failure, all this information is lost and the server needs to recover it on restart. In the basic setup this is done starting over the Discovery process. Given that servers usually have lots of clients associated, this is very time consuming.

Alternatively, Fast DDS allows to synchronize the server’s discovery record to a file, so that the information can be loaded back into memory during the restart. This feature is enabled specifying the Discovery Protocol as BACKUP.

The record file is located on the server’s process working directory, and named following the pattern server-<GUIDPREFIX>.db (for example: server-73-65-72-76-65-72-63-6C-69-65-6E-74.db). Once the server is created, it automatically looks for this file. If it already exists, its contents are loaded, avoiding the need of re-discovering the clients. To make a fresh restart, any such backup file must be removed or renamed before launching the server.

## 13.1.3.4. UDPv4 partitioning using servers¶

Server association can be seen as another isolation mechanism besides Domains and Partitions. Clients that do not share a server cannot see each other and belong to isolated server networks. For example, in the following figure, client 1 and client 2 cannot communicate even if they are on the same physical network and Domain.

Clients cannot see each other due to server isolation

However, it is possible to connect server isolated networks very much as physical networks can be connected through routers:

• Option 1: Connecting the clients to several servers, so that the clients belong several networks.

• Option 2: Connecting one server to another, so that the networks are linked together.

• Option 3: Create a new server linked to the servers to which the clients are connected.

Options 1 and 2 can only be implemented by modifying QoS values or XML configuration files beforehand. In this regard they match the domain and partition strategy. Option 3, however, can be implemented at runtime, when the isolated networks are already up and running.

### 13.1.3.4.1. Option 1¶

Connect each client to both servers. This case matches the redundancy use case already introduced.

### 13.1.3.4.2. Option 2¶

Connect one server to the other. This means configuring one of the servers to act as client of the other.

Consider two servers, each one managing an isolated network:

Network

Prefix

A

75.63.2D.73.76.72.63.6C.6E.74.2D.31

192.168.10.60:56543

B

75.63.2D.73.76.72.63.6C.6E.74.2D.32

192.168.10.57:56542

In order to communicate both networks we can set server A to act as client of server B:

 C++ DomainParticipantQos qos; // Configure current Participant as SERVER on address 192.168.10.60 Locator_t server_locator; IPLocator::setIPv4(server_locator, "192.168.10.60"); server_locator.port = 56543; qos.wire_protocol().builtin.discovery_config.discoveryProtocol = DiscoveryProtocol_t::SERVER; std::istringstream("75.63.2D.73.76.72.63.6C.6E.74.2D.31") >> qos.wire_protocol().prefix; qos.wire_protocol().builtin.metatrafficUnicastLocatorList.push_back(server_locator); // Add the connection attributes to the remote server. Locator_t remote_server_locator; IPLocator::setIPv4(remote_server_locator, "192.168.10.57"); remote_server_locator.port = 56542; RemoteServerAttributes remote_server_attr; remote_server_attr.ReadguidPrefix("75.63.2D.73.76.72.63.6C.6E.74.2D.32"); remote_server_attr.metatrafficUnicastLocatorList.push_back(remote_server_locator); qos.wire_protocol().builtin.discovery_config.m_DiscoveryServers.push_back(remote_server_attr);  XML  75.63.2D.73.76.72.63.6C.6E.74.2D.31 SERVER
192.168.10.57
56542
192.168.10.60
56543


### 13.1.3.4.3. Option 3¶

Create a new server linked to the servers to which the clients are connected.

Consider two servers (A and B), each one managing an isolated network, and a third server (C) that will be used to connect the first two:

Server

Prefix

A

75.63.2D.73.76.72.63.6C.6E.74.2D.31

192.168.10.60:56543

B

75.63.2D.73.76.72.63.6C.6E.74.2D.32

192.168.10.57:56542

C

75.63.2D.73.76.72.63.6C.6E.74.2D.33

192.168.10.54:56541

In order to communicate both networks we can setup server C to act as client of servers A and B as follows:

 C++ DomainParticipantQos qos; // Configure current Participant as SERVER on address 192.168.10.60 Locator_t server_locator; IPLocator::setIPv4(server_locator, "192.168.10.54"); server_locator.port = 56541; qos.wire_protocol().builtin.discovery_config.discoveryProtocol = DiscoveryProtocol_t::SERVER; std::istringstream("75.63.2D.73.76.72.63.6C.6E.74.2D.33") >> qos.wire_protocol().prefix; qos.wire_protocol().builtin.metatrafficUnicastLocatorList.push_back(server_locator); // Add the connection attributes to the remote server A. Locator_t remote_server_locator_A; IPLocator::setIPv4(remote_server_locator_A, "192.168.10.60"); remote_server_locator_A.port = 56543; RemoteServerAttributes remote_server_attr_A; remote_server_attr_A.ReadguidPrefix("75.63.2D.73.76.72.63.6C.6E.74.2D.31"); remote_server_attr_A.metatrafficUnicastLocatorList.push_back(remote_server_locator_A); qos.wire_protocol().builtin.discovery_config.m_DiscoveryServers.push_back(remote_server_attr_A); // Add the connection attributes to the remote server B. Locator_t remote_server_locator_B; IPLocator::setIPv4(remote_server_locator_B, "192.168.10.57"); remote_server_locator_B.port = 56542; RemoteServerAttributes remote_server_attr_B; remote_server_attr_B.ReadguidPrefix("75.63.2D.73.76.72.63.6C.6E.74.2D.32"); remote_server_attr_B.metatrafficUnicastLocatorList.push_back(remote_server_locator_B); qos.wire_protocol().builtin.discovery_config.m_DiscoveryServers.push_back(remote_server_attr_B);  XML  75.63.2D.73.76.72.63.6C.6E.74.2D.33 SERVER
192.168.10.57
56542
192.168.10.60
56543
192.168.10.54
56541