Skip to content

Commit

Permalink
Fix spelling mistakes in the docs (#549)
Browse files Browse the repository at this point in the history
Signed-off-by: tempate <[email protected]>
  • Loading branch information
Tempate authored Sep 19, 2023
1 parent d5f5ffd commit 2a55bb9
Show file tree
Hide file tree
Showing 7 changed files with 18 additions and 18 deletions.
6 changes: 3 additions & 3 deletions docs/fastdds/discovery/discovery_server.rst
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@ In this architecture there are several key concepts to understand:
|DataWriters| and |DataReaders|.

- Discovery Server DomainParticipants may be *clients* or *servers*.
The only difference between them is on how they handle discovery traffic.
The only difference between them is how they handle discovery traffic.
The user traffic, that is, the traffic among the DataWriters and DataReaders they create, is role-independent.

- All *server* and *client* discovery information will be shared with linked *clients*.
Expand All @@ -66,7 +66,7 @@ In this architecture there are several key concepts to understand:
- 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.

- *Clients* require a beforehand knowledge of the *servers* to which they want to link.
- *Clients* require prior knowledge of the *servers* to which they want to link.
Basically it is reduced to the *servers* identity (henceforth called |GuidPrefix_t-api|) and a list of locators
where the *servers* are listening.
These locators also define the transport protocol (UDP or TCP) the client will use to contact the *server*.
Expand All @@ -88,7 +88,7 @@ In this architecture there are several key concepts to understand:
which it is connected.
Any DomainParticipant discovered by the *Server* with no endpoints will not be known by the |SUPER_CLIENT|.

- *Servers* do not require any beforehand knowledge of their *clients*, but their |GuidPrefix_t-api| and locator list
- *Servers* do not require any prior knowledge of their *clients*, but their |GuidPrefix_t-api| and locator list
(where they are listening) must match the one provided to the *clients*.
*Clients* send discovery messages to the *servers* at regular intervals (ping period) until they receive message
reception acknowledgement.
Expand Down
4 changes: 2 additions & 2 deletions docs/fastdds/discovery/general_disc_settings.rst
Original file line number Diff line number Diff line change
Expand Up @@ -45,7 +45,7 @@ The possible values are:
+---------------------+---------------------+--------------------------------------------------------------------------+
| Discovery Mechanism | Possible values | Description |
+=====================+=====================+==========================================================================+
| Simple | |SIMPLE| | Simple discovery protocol as specified in |
| Simple | |SIMPLE| | Simple discovery protocol as specified in the |
| | | `RTPS standard <https://www.omg.org/spec/DDSI-RTPS/2.2/PDF>`_. |
+---------------------+---------------------+--------------------------------------------------------------------------+
| Static | |STATIC| | SPDP with manual EDP specified in XML files. |
Expand All @@ -66,7 +66,7 @@ The possible values are:
| | | This type of sever makes the Discovery Server architecture |br| |
| | | resilient to server destruction. |
+---------------------+---------------------+--------------------------------------------------------------------------+
| Manual | |NONE| | Disables PDP phase, therefore the is no EDP phase. |br| |
| Manual | |NONE| | Disables PDP phase, therefore there is no EDP phase. |br| |
| | | All matching must be done manually through the |br| |
| | | ``addReaderLocator``, ``addReaderProxy``, ``addWriterProxy`` |br| |
| | | RTPS layer methods. |
Expand Down
6 changes: 3 additions & 3 deletions docs/fastdds/discovery/simple.rst
Original file line number Diff line number Diff line change
Expand Up @@ -80,8 +80,8 @@ Simple EDP Attributes
| Name | Description | Type | Default |
+=============================+================================================================+=============+=========+
| SIMPLE EDP | It defines the use of the SIMPLE protocol as a discovery |br| | ``bool`` | true |
| | protocol for EDP phase. A DomainParticipant may create |br| | | |
| | DataWriters, DataReaders, both or neither. | | |
| | protocol for the EDP phase. A DomainParticipant may |br| | | |
| | create DataWriters, DataReaders, both or neither. | | |
+-----------------------------+----------------------------------------------------------------+-------------+---------+
| Publication writer and |br| | It is intended for DomainParticipants that implement only |br| | ``bool`` | true |
| Subscription reader | one or more DataWriters, i.e. do not implement DataReaders. | | |
Expand Down Expand Up @@ -119,7 +119,7 @@ Initial peers
According to the `RTPS standard <https://www.omg.org/spec/DDSI-RTPS/2.2/PDF>`_ (Section 9.6.1.1), each
|RTPSParticipant-api|
must listen for incoming Participant Discovery Protocol (PDP) discovery metatraffic in two different ports, one linked
with a multicast address, and another one linked to a unicast address.
to a multicast address and another one linked to a unicast address.
*Fast DDS* allows for the configuration of an initial peers list which contains one or more such 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,
Expand Down
6 changes: 3 additions & 3 deletions docs/fastdds/transport/shared_memory/shared_memory.rst
Original file line number Diff line number Diff line change
Expand Up @@ -40,9 +40,9 @@ This is mainly due to the following reasons:
Definition of Concepts
----------------------

This section describes basic concepts that will help understanding how the Shared Memory Transport works in order
This section describes basic concepts to help explain how the Shared Memory Transport works in order
to deliver the data messages to the appropriate :ref:`dds_layer_domainParticipant`.
The purpose is not to be a exhaustive reference of the implementation, but to be a comprehensive explanation
The purpose is not to be an exhaustive reference of the implementation, but to be a comprehensive explanation
of each concept, so that users can configure the transport to their needs.

Many of the descriptions in this section will be made following the example use case depicted in the following figure,
Expand Down Expand Up @@ -74,7 +74,7 @@ shared memory mechanisms.
can lead to communication problems, as processes run by non-privileged users may
not be able to write into the memory segment.

Every segment has a *segmentId*, a 16 character UUID that uniquely identifies each shared memory segment.
Every segment has a *segmentId*, a 16-character UUID that uniquely identifies each shared memory segment.
These *segmentIds* are used to identify and access the segment of each DomainParticipant.

.. _transport_sharedMemory_concepts_buffer:
Expand Down
6 changes: 3 additions & 3 deletions docs/fastdds/use_cases/large_data/large_data.rst
Original file line number Diff line number Diff line change
Expand Up @@ -37,12 +37,12 @@ In this scenario, several limitations have to be taken into account:

*eProsima Fast DDS* defines a conservative default message size of 64kB,
which roughly corresponds to TCP and UDP payload sizes.
If the topic data is bigger, it will automatically be be fragmented into several transport packets.
If the topic data is bigger, it will automatically be fragmented into several transport packets.

.. warning::

The loss of a fragment means the loss of the entire message.
This has most impact on |BEST_EFFORT_RELIABILITY_QOS-api| mode, where the message loss
This has the most impact on |BEST_EFFORT_RELIABILITY_QOS-api| mode, where the message loss
probability increases with the number of fragments


Expand Down Expand Up @@ -167,7 +167,7 @@ The settings for a specific network adapter can be viewed using the one of the f
ifconfig ${interface}
This will display the configuration of the adapter, and among the parameters the ``txqueuelen``.
This parameter can be a value between a 1000 and 20000.
This parameter can be a value between 1000 and 20000.

.. important::

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -36,7 +36,7 @@ This reduces the amount of meta traffic if not all the DomainParticipants
need to be aware of all the rest of the remote participants present in the network.

Use-case :ref:`use-case-fast-rtps-over-wifi` provides a detailed explanation on how to configure *Fast DDS* for such
case.
cases.

.. _wide_deployments_static_edp:

Expand Down
6 changes: 3 additions & 3 deletions docs/fastdds/use_cases/wifi/discovery_server_use_case.rst
Original file line number Diff line number Diff line change
Expand Up @@ -254,7 +254,7 @@ However, it is possible to connect server isolated networks very much as physica
can be connected through routers:

* :ref:`discovery_server_partitioning_option1`:
Connecting the clients to several servers, so that the clients belong several networks.
Connecting the clients to several servers, so that the clients belong to several networks.
* :ref:`discovery_server_partitioning_option2`:
Connecting one server to another, so that the networks are linked together.
* :ref:`discovery_server_partitioning_option3`:
Expand Down Expand Up @@ -339,7 +339,7 @@ Option 2
^^^^^^^^

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

Consider two servers, each one managing an isolated network:

Expand All @@ -350,7 +350,7 @@ Consider two servers, each one managing an isolated network:
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:
In order to communicate both networks we can set server A to act as a client of server B:

+--------------------------------------------------------+
| **C++** |
Expand Down

0 comments on commit 2a55bb9

Please sign in to comment.