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/logging/logging.rst

@@ -81,7 +81,7 @@ Logging Frequently Asked Questions
 
     |br|
 
-    Filters are applied in the specific order presented above, meaning that file name filtering is only applied to the entries that pattern-match the category filter, and content filtering is only applied to the entries that pattern-match both category and file name filters. For further information, go to :ref:`dds_layer_log_filter`.
+    Filters are applied in the specific order presented in the previous question, meaning that file name filtering is only applied to the entries that pattern-match the category filter, and content filtering is only applied to the entries that pattern-match both category and file name filters. For further information, go to :ref:`dds_layer_log_filter`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 

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/security/security.rst

@@ -8,14 +8,14 @@ Security Frequently Asked Questions
 ===================================
 
 
- .. collapse::  Why is Fast DDS communication secure?
+ .. collapse::  What security plugins does Fast DDS offer for secure communication?
 
 
 
 
     |br|
 
-    Because it implements pluggable security at three levels: authentication, access control, and data encryption. For further information, see :ref:`security`.
+    Fast DDS offers five built-in security plugins as part of the DDS Security specification: the Authentication plugin (:ref:`auth-pki-dh`) provides authentication between DomainParticipants using a trusted Certificate Authority (CA) and mutual authentication; the Access Control plugin (:ref:`access-permissions`) enforces permissions for protected operations; the Cryptographic plugin (:ref:`crypto-aes-gcm-gmac`) ensures authenticated encryption and data integrity using AES in Galois Counter Mode (AES-GCM); the Logging plugin (:ref:`logging-logtopic`) logs security-related events. For further information, see :ref:`security`.
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
@@ -67,6 +67,14 @@ Authentication
 
 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
+.. collapse::  What is the process for generating and managing security certificates for the Authentication plugin?
+
+
+
+
+    |br| The process for generating and managing security certificates for the Authentication plugin involves creating and managing X.509 certificates. First, since multiple certificates will need to be issued, one for each of the DomainParticipants, a dedicated CA is set up, and the CA’s certificate is installed as the root key of all DomainParticipants. Thus, the DomainParticipants will accept all certificates issued by our own CA. To create a proprietary CA certificate, a configuration file must first be written with the CA information. After writing the configuration file, the certificate  is generates using the Elliptic Curve Digital Signature Algorithm (ECDSA). As was done for the CA, a DomainParticipant certificate configuration file needs to be created first. After writing the DomainParticipant certificate configuration file, the X.509 certificate is generated using ECDSA, for a DomainParticipant. Finally, the CRL is created. This is a list of the X.509 certificates revoked by the certificate issuing CA before they reach their expiration date. Any certificate that is on this list will no longer be trusted. For further information, see :ref:`generate_x509`.
+
+-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
 
 Access control
 --------------