Add review changes

Signed-off-by: Denisa <[email protected]>

docs/03-exports/aliases-api.include

@@ -885,6 +885,7 @@
 .. |EntityId_t-api| replace:: :cpp:struct:`EntityId_t<eprosima::fastdds::rtps::EntityId_t>`
 .. |InitialAnnouncementConfig-api| replace:: :cpp:struct:`InitialAnnouncementConfig<eprosima::fastdds::rtps::InitialAnnouncementConfig>`
 .. |InitialAnnouncementConfig::period-api| replace:: :cpp:member:`period<eprosima::fastdds::rtps::InitialAnnouncementConfig::period>`
+.. |InitialAnnouncementConfig::count-api| replace:: :cpp:member:`count<eprosima::fastdds::rtps::InitialAnnouncementConfig::count>`
 .. |BuiltinAttributes-api| replace:: :cpp:class:`BuiltinAttributes<eprosima::fastdds::rtps::BuiltinAttributes>`
 .. |BuiltinAttributes::discovery_config-api| replace:: :cpp:member:`discovery_config<eprosima::fastdds::rtps::BuiltinAttributes::discovery_config>`
 .. |BuiltinAttributes::metatrafficUnicastLocatorList-api| replace:: :cpp:member:`metatrafficUnicastLocatorList<eprosima::fastdds::rtps::BuiltinAttributes::metatrafficUnicastLocatorList>`

docs/fastdds/faq/discovery/discovery.rst

@@ -31,6 +31,15 @@ Discovery Frequently Asked Questions
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
+.. 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?
+
+
+    |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. This increases the likelihood that DomainParticipants will detect each other despite potential network disruptions or message loss. By adjusting the |InitialAnnouncementConfig::count-api| (number of announcements) and |InitialAnnouncementConfig::period-api| (interval between announcements), you can optimize discovery reliability during startup. For further information, go to :ref:`simple_disc_settings`.
+
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
 .. collapse::  What is an initial peer list?
 
 
@@ -71,7 +80,7 @@ Discovery Frequently Asked Questions
 
     |br|
 
-    The role of the server is to redistribute its clients' discovery information to its known clients and servers. For further information, go to :ref:`discovery_server`.
+    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. 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. It also facilitates server-to-server connections, enabling a more scalable discovery process across the network. For further information, go to :ref:`discovery_server`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 

docs/fastdds/faq/faq.rst

@@ -13,8 +13,8 @@ This section answers to frequently asked questions about FastDDS.
     getting_started/getting_started
     dds_layer/dds_layer
     rtps_layer/rtps_layer
-    transport_layer/transport_layer
     discovery/discovery
+    transport_layer/transport_layer
     persistence_service/persistence_service
     security/security
     logging/logging

docs/fastdds/faq/getting_started/getting_started.rst

@@ -26,7 +26,7 @@ Frequently Asked Getting Started Questions
 
     |br|
 
-    There are four basic entities: |Publisher|, |Subscriber|, |Topic|, |domain|. For further information, go to :ref:`what_is_dds`.
+    These are the basic entities of a DDS: |Publisher|, |Subscriber|, |DataReader|, |DataWriter|, |Topic|, |domain|. For further information, go to :ref:`what_is_dds`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
@@ -48,7 +48,15 @@ Frequently Asked Getting Started Questions
 
     |br|
 
-    |Publisher-api|. It is the DCPS entity in charge of the creation and configuration of the DataWriters it implements. The  |DataWriter-api| is the entity in charge of the actual publication of the messages. Each one will have an assigned Topic under which the messages are published. For further information, go to :ref:`dds_layer_publisher`.
+    |Publisher-api|. It is the Data-Centric Publish Subscribe entity in charge of the creation and configuration of the DataWriters it implements. The  |DataWriter-api| is the entity in charge of the actual publication of the messages. Each one will have an assigned Topic under which the messages are published. For further information, go to :ref:`dds_layer_publisher`.
+
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+.. collapse::  What is the primary responsibility of a DDS Subscriber entity?
+
+    |br|
+
+    |Subscriber-api|.  It is the DCPS Entity in charge of receiving the data published under the topics to which it subscribes. It serves one or more DataReader objects, which are responsible for communicating the availability of new data to the application. See :ref:`dds_layer_subscriber` for further details.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
@@ -59,7 +67,7 @@ Frequently Asked Getting Started Questions
 
     |br|
 
-    Domain. This is the concept used to link all publishers and subscribers, belonging to one or more applications, which exchange data under different topics. These individual applications that participate in a domain are called DomainParticipant. The DDS Domain is identified by a domain ID. For further information, go to :ref:`dds_layer_domain`.
+    |Domain|. This is the concept used to link all publishers and subscribers, belonging to one or more applications, which exchange data under different topics. These individual applications that participate in a domain are called |DomainParticipant-api|. The DDS Domain is identified by a domain ID. Domains create logical separations among the entities that share a common communication infrastructure. They isolate applications running in the same domain from applications running on different domains. For further information, go to :ref:`dds_layer_domain`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
@@ -70,7 +78,7 @@ Frequently Asked Getting Started Questions
 
     |br|
 
-    The Real-Time Publish Subscribe (RTPS) protocol, developed to support DDS applications, is a publication-subscription communication middleware over transports such as UDP/IP. For further information, go to :ref:`what_is_rtps`.
+    The Real-Time Publish Subscribe (RTPS) protocol, developed to support DDS applications, is a publication-subscription communication middleware over transports such as UDP/IP. RTPS supports unicast and multicast communications, organizing communication within independent domains containing RTPSParticipants, which use RTPSWriters to send data and RTPSReaders to receive data, all centered around Topics that label exchanged data. For further information, go to :ref:`what_is_rtps`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 

docs/fastdds/faq/rtps_layer/rtps_layer.rst

@@ -50,4 +50,14 @@ RTPS LAYER Frequently Asked Questions
 
     In the RTPS Protocol, Readers and Writers save the data about a topic in their associated Histories. Each piece of data is represented by a Change, which *eprosima Fast DDS* implements as ``CacheChange_t``. Changes are always managed by the History. For further information, see :ref:`rtps_layer`.
 
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
+.. collapse::  How can a custom Payload Pool improve the performance of Writers and Readers in RTPS, and what should be considered when implementing one?
+
+
+
+    |br|
+
+    A custom payload pool can improve the performance of writers and readers in RTPS by optimizing memory usage and reducing costly memory allocation operations, especially when dealing with large or variable-sized data. When implementing one, it is essential to ensure that the payload size accommodates the serialized user data plus metadata, and to choose a strategy (e.g., preallocated, dynamic) that balances memory usage and allocation efficiency based on application needs. For further information, see :ref:`rtps_layer_custom_payload_pool`.
+
 |

docs/fastdds/faq/transport_layer/transport_layer.rst

@@ -55,7 +55,7 @@ Transport API
 
     |br|
 
-    A ``Locator_t`` uniquely identifies a communication channel with a remote peer for a particular transport. For further information, see :ref:`transport_transportApi_locator`.
+    A ``Locator_t`` uniquely identifies a communication channel with a remote peer for a particular transport.  For example, on UDP transports, the Locator will contain the information of the IP address and port of the remote peer. The listening Locators, such as Multicast locators(listen to multicast communications), Unicast locators(listen to unicast communications), Metatraffic locators(used to receive metatraffic information, usually used by built-in endpoints to perform discovery), User locators(used by the endpoints created by the user to receive user Topic data changes), are used to receive incoming traffic on the DomainParticipant. For further information, see :ref:`transport_transportApi_locator`.
 
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
@@ -181,7 +181,7 @@ TCP Transport
 
     |br|
 
-    The |TCPv4TransportDescriptor-api| must indicate its public IP address in the "wan_addr" data member. On the client side, the DomainParticipant must be configured with the public IP address and "listening_ports" of the TCP as Initial peers.
+    The |TCPv4TransportDescriptor-api| must indicate its public IP address in the "wan_addr" data member. On the client side, the DomainParticipant must be configured with the public IP address and "listening_ports" of the TCP as Initial peers. For further information, see :ref:`transport_tcp_wan`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
@@ -196,6 +196,16 @@ TCP Transport
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
+.. collapse:: What are the advantages and disadvantages of using TCP transport compared to UDP transport?
+
+
+
+    |br|
+
+    TCP offers reliable data transmission with built-in mechanisms for error detection, correction, and ordered delivery of packets, ensuring data integrity and sequencing. It also includes flow control to adjust the transmission rate between sender and receiver. However, this reliability comes with increased overhead, resulting in slower transmission speeds and higher latency compared to UDP. UDP, on the other hand, is faster with lower latency, as it does not ensure packet delivery, order, or perform error correction, making it ideal for real-time applications like video streaming or gaming, but less reliable for applications requiring data accuracy.
+
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
+
 Shared Memory Transport
 -----------------------
 
@@ -311,7 +321,7 @@ Data Sharing Delivery
 
     |br|
 
-    No, it does not prevent data copies. For further information, see :ref:`datasharing-delivery`.
+    No, it does not prevent data copies. Data-sharing helps avoid copies between the DataWriter and DataReader by using shared memory for communication, but data still needs to be copied between the application and the DataWriter or DataReader. To avoid these copies, a different mechanism, such as Zero-Copy communication, is required.  For further information, see :ref:`datasharing-delivery`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 

docs/spelling_wordlist.txt

@@ -319,4 +319,5 @@ verbosities
 segmentId
 addr
 faq
+reachability