-
-
-
-
-
+
+
+
+
+
@@ -37,20 +37,22 @@
-*eprosima Fast DDS* (formerly Fast RTPS) is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group). eProsima Fast DDS implements the RTPS (Real Time Publish Subscribe) protocol, which provides publisher-subscriber communications over unreliable transports such as UDP,
-as defined and maintained by the Object Management Group (OMG) consortium. RTPS is also the wire interoperability protocol defined for the Data Distribution
-Service (DDS) standard. *eProsima Fast DDS* expose an API to access directly the RTPS protocol, giving the user full access to the protocol internals.
+
+> [!WARNING]
+> **In preparation for v3.0.0, Fast DDS' master branch is undergoing major changes entailing API breaks.**
+> **Until Fast DDS v3.0.0 is released, it is strongly advisable to use the latest stable branch, [2.14.x](https://github.com/eProsima/Fast-DDS/tree/2.14.x)**.
+
+*eprosima Fast DDS* is a C++ implementation of the DDS (Data Distribution Service) standard of the OMG (Object Management Group).
+eProsima Fast DDS implements the RTPS (Real Time Publish Subscribe) protocol, which provides publisher-subscriber communications over unreliable transports such as UDP, as defined and maintained by the Object Management Group (OMG) consortium.
+RTPS is also the wire interoperability protocol defined for the Data Distribution Service (DDS) standard.
+*eProsima Fast DDS* expose an API to access directly the RTPS protocol, giving the user full access to the protocol internals.
Some of the main features of this library are:
-* Configurable best-effort and reliable publish-subscribe communication policies for real-time
-applications.
-* Plug and play connectivity so that any new applications are automatically discovered by any other
-members of the network.
-* Modularity and scalability to allow continuous growth with complex and simple devices in the
-network.
-* Configurable network behavior and interchangeable transport layer: Choose the best protocol and
-system input/output channel combination for each deployment.
+* Configurable best-effort and reliable publish-subscribe communication policies for real-time applications.
+* Plug and play connectivity so that any new applications are automatically discovered by any other members of the network.
+* Modularity and scalability to allow continuous growth with complex and simple devices in the network.
+* Configurable network behavior and interchangeable transport layer: Choose the best protocol and system input/output channel combination for each deployment.
* Two API Layers: a high-level Publisher-Subscriber one focused on usability (DDS) and a lower-level Writer-Reader one that provides finer access to the inner workings of the RTPS protocol.
*eProsima Fast DDS* has been adopted by multiple organizations in many sectors including these important cases:
@@ -58,8 +60,8 @@ system input/output channel combination for each deployment.
* Robotics: ROS (Robotic Operating System) as their default middleware for every ROS 2 long term (LTS) releases and most of the non-LTS releases.
* EU R&D: FIWARE Incubated GE.
-This project is part of [FIWARE](https://www.fiware.org/). For more information check the FIWARE Catalogue entry for
-[Robotics](https://github.com/Fiware/catalogue/tree/master/robotics).
+This project is part of [FIWARE](https://www.fiware.org/).
+For more information check the FIWARE Catalogue entry for [Robotics](https://github.com/Fiware/catalogue/tree/master/robotics).
## Want us to share your project with the community?
@@ -96,13 +98,13 @@ You can access the documentation online, which is hosted on [Read the Docs](http
## Quality Declaration
-*eprosima Fast DDS* claims to be in the **Quality Level 1** category based on the guidelines provided by
-[ROS 2](https://ros.org/reps/rep-2004.html).
+*eprosima Fast DDS* claims to be in the **Quality Level 1** category based on the guidelines provided by [ROS 2](https://ros.org/reps/rep-2004.html).
See the [Quality Declaration](https://github.com/eProsima/Fast-DDS/blob/master/QUALITY.md) for more details.
## Quick Demo
-eProsima provides the eProsima Fast DDS Suite Docker image for those who want a quick demonstration of Fast-DDS running on an Ubuntu platform. It can be downloaded from [eProsima's downloads page](https://eprosima.com/index.php/downloads-all).
+eProsima provides the eProsima Fast DDS Suite Docker image for those who want a quick demonstration of Fast DDS running on an Ubuntu platform.
+It can be downloaded from [eProsima's downloads page](https://eprosima.com/index.php/downloads-all).
This Docker image was built for Ubuntu 20.04 (Focal Fossa).
@@ -125,54 +127,44 @@ This Docker Image comes bundled with the following:
### Shapes Demo
-eProsima Shapes Demo is an application in which Publishers and Subscribers are shapes of different
-colors and sizes moving on a board. Each shape refers to its own topic: Square, Triangle or Circle.
-A single instance of the eProsima Shapes Demo can publish on or subscribe to several topics at a
-time.
+eProsima Shapes Demo is an application in which Publishers and Subscribers are shapes of different colors and sizes moving on a board.
+Each shape refers to its own topic: Square, Triangle or Circle.
+A single instance of the eProsima Shapes Demo can publish on or subscribe to several topics at a time.
-You can read more about this application on the
-[Shapes Demo documentation page](https://eprosima-shapes-demo.readthedocs.io/).
+You can read more about this application on the [Shapes Demo documentation page](https://eprosima-shapes-demo.readthedocs.io/).
To run this application once inside the Docker container run:
$ ShapesDemo
-eProsima Shapes Demo usage information can be found on the
-[Shapes Demo First Steps page](https://eprosima-shapes-demo.readthedocs.io/en/latest/first_steps/first_steps.html).
+eProsima Shapes Demo usage information can be found on the [Shapes Demo First Steps page](https://eprosima-shapes-demo.readthedocs.io/en/latest/first_steps/first_steps.html).
### Fast DDS Monitor
-eProsima Fast DDS Monitor is a graphical desktop application aimed at monitoring DDS environments
-deployed using the *eProsima Fast DDS* library. Thus, the user can monitor in real time the status
-of publication/subscription communications between DDS entities. They can also choose from a wide
-variety of communication parameters to be measured (latency, throughput,packet loss, etc.), as well
-as record and compute in real time statistical measurements on these parameters (mean, variance,
-standard deviation, etc.).
+eProsima Fast DDS Monitor is a graphical desktop application aimed at monitoring DDS environments deployed using the *eProsima Fast DDS* library.
+Thus, the user can monitor in real time the status of publication/subscription communications between DDS entities.
+They can also choose from a wide variety of communication parameters to be measured (latency, throughput,packet loss, etc.), as well as record and compute in real time statistical measurements on these parameters (mean, variance, standard deviation, etc.).
-You can read more about this application on the
-[Fast DDS Monitor documentation page](https://fast-dds-monitor.readthedocs.io/).
+You can read more about this application on the [Fast DDS Monitor documentation page](https://fast-dds-monitor.readthedocs.io/).
To run this application once inside the Docker container run:
$ fastdds_monitor
-eProsima Fast DDS Monitor usage information can be found on the
-[Fast DDS Monitor User Manual](
-https://fast-dds-monitor.readthedocs.io/en/latest/rst/user_manual/initialize_monitoring.html).
+eProsima Fast DDS Monitor usage information can be found on the [Fast DDS Monitor User Manual](https://fast-dds-monitor.readthedocs.io/en/latest/rst/user_manual/initialize_monitoring.html).
### Fast DDS libraries and Examples
-Included in this Docker container is a set of binary examples that showcase several functionalities of the
-Fast DDS libraries. These examples' path can be accessed from a terminal by typing
+Included in this Docker container is a set of binary examples that showcase several functionalities of the Fast DDS libraries.
+These examples' path can be accessed from a terminal by typing
$ goToExamples
-From this folder you can access all examples, both for DDS and RTPS. We detail the steps to launch two such
-examples below.
+From this folder you can access all examples, both for DDS and RTPS.
+We detail the steps to launch two such examples below.
-To launch the Hello World example (a minimal example that will perform a Publisher/Subscriber match and start
-sending samples) you could run:
+To launch the Hello World example (a minimal example that will perform a Publisher/Subscriber match and start sending samples) you could run:
$ goToExamples
$ cd dds/HelloWorldExample/bin
@@ -180,8 +172,8 @@ sending samples) you could run:
split-window "./HelloWorldExample subscriber" \; \
select-layout even-vertical
-This example is not constrained to the current instance. It's possible to run several instances of this
-container to check the communication between them by running the following from each container.
+This example is not constrained to the current instance.
+It is possible to run several instances of this container to check the communication between them by running the following from each container.
$ goToExamples
$ cd dds/HelloWorldExample/bin
@@ -193,9 +185,9 @@ or
$ cd dds/HelloWorldExample/bin
$ ./HelloWorldExample subscriber
-Another example you could launch is the Benchmark example. This example creates either a Publisher or a Subscriber and
-on a successful match starts sending samples. After a few seconds the process that launched the Publisher will show
-a report with the number of samples transmitted.
+Another example you could launch is the Benchmark example.
+This example creates either a Publisher or a Subscriber and on a successful match starts sending samples.
+After a few seconds the process that launched the Publisher will show a report with the number of samples transmitted.
On the subscriber side, run:
@@ -235,5 +227,4 @@ More information:
rosin-project.eu
-This project has received funding from the European Unionβs Horizon 2020
-research and innovation programme under grant agreement no. 732287.
+This project has received funding from the European Unionβs Horizon 2020 research and innovation programme under grant agreement no. 732287.
diff --git a/UPGRADING.md b/UPGRADING.md
index 59a4631d489..d9344f7438c 100644
--- a/UPGRADING.md
+++ b/UPGRADING.md
@@ -1,6 +1,6 @@
Upgrading from previous versions
================================
-If you have used *fastrtpsgen* to generate part of your code, it is always *recommended* to regenerate it.
+If you have used *fastddsgen* to generate part of your code, it is always *recommended* to regenerate it.
When upgrading from a version older than 1.7.0, regeneration is **required**.
diff --git a/build_qnx/common.mk b/build_qnx/common.mk
index e5bbef9c544..b9d694d8cb9 100644
--- a/build_qnx/common.mk
+++ b/build_qnx/common.mk
@@ -12,7 +12,7 @@ NAME=Fast-DDS
FAST-DDS_INSTALL_ROOT ?= $(INSTALL_ROOT_$(OS))
# These commands require GNU Make
-FAST-DDS_CMAKE_VERSION = $(shell bash -c "grep VERSION $(PROJECT_ROOT)/../CMakeLists.txt | grep fastrtps ")
+FAST-DDS_CMAKE_VERSION = $(shell bash -c "grep VERSION $(PROJECT_ROOT)/../CMakeLists.txt | grep fastdds ")
FAST-DDS_VERSION = .$(subst $\",,$(word 3,$(FAST-DDS_CMAKE_VERSION)))
#choose Release or Debug
diff --git a/cmake/modules/FindTinyXML2.cmake b/cmake/modules/FindTinyXML2.cmake
index 44b8e645758..c05986ad7f9 100644
--- a/cmake/modules/FindTinyXML2.cmake
+++ b/cmake/modules/FindTinyXML2.cmake
@@ -2,7 +2,7 @@
# TINYXML2_INCLUDE_DIR
# TINYXML2_SOURCE_DIR
-option(TINYXML2_FROM_SOURCE "Integrate TinyXML2 source code inside Fast RTPS" OFF)
+option(TINYXML2_FROM_SOURCE "Integrate TinyXML2 source code inside Fast DDS" OFF)
# Option for evaluating whether we are looking in for tinyxml2 in submodule
set(TINYXML2_FROM_THIRDPARTY OFF)
diff --git a/cmake/packaging/Config.cmake.in b/cmake/packaging/Config.cmake.in
index 01693a9a802..ea462700f8f 100644
--- a/cmake/packaging/Config.cmake.in
+++ b/cmake/packaging/Config.cmake.in
@@ -16,7 +16,7 @@ set(@PROJECT_NAME@_VERSION @PROJECT_VERSION@)
@PACKAGE_INIT@
-@FASTRTPS_PACKAGE_OPT_BIN_DIR_CONDITION@
+@FASTDDS_PACKAGE_OPT_BIN_DIR_CONDITION@
set_and_check(@PROJECT_NAME@_BIN_DIR "@PACKAGE_BIN_INSTALL_DIR@")
endif()
set_and_check(@PROJECT_NAME@_INCLUDE_DIR "@PACKAGE_INCLUDE_INSTALL_DIR@")
@@ -25,67 +25,67 @@ set_and_check(@PROJECT_NAME@_LIB_DIR "@PACKAGE_LIB_INSTALL_DIR@")
find_package(fastcdr REQUIRED)
find_package(foonathan_memory REQUIRED)
find_package(TinyXML2 QUIET)
-@FASTRTPS_INSTALLER_DEPS_ANCILLARY@
-@FASTRTPS_PACKAGE_UNIX_OPT_DEPS@
+@FASTDDS_INSTALLER_DEPS_ANCILLARY@
+@FASTDDS_PACKAGE_UNIX_OPT_DEPS@
-set(fastrtps_known_comps static shared)
-set(fastrtps_comp_static NO)
-set(fastrtps_comp_shared NO)
-foreach (fastrtps_comp IN LISTS ${CMAKE_FIND_PACKAGE_NAME}_FIND_COMPONENTS)
- if (fastrtps_comp IN_LIST fastrtps_known_comps)
- set(fastrtps_comp_${fastrtps_comp} YES)
+set(fastdds_known_comps static shared)
+set(fastdds_comp_static NO)
+set(fastdds_comp_shared NO)
+foreach (fastdds_comp IN LISTS ${CMAKE_FIND_PACKAGE_NAME}_FIND_COMPONENTS)
+ if (fastdds_comp IN_LIST fastdds_known_comps)
+ set(fastdds_comp_${fastdds_comp} YES)
else ()
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
- "fastrtps does not recognize component `${fastrtps_comp}`.")
+ "fastdds does not recognize component `${fastdds_comp}`.")
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
return()
endif ()
endforeach ()
-if (fastrtps_comp_static AND fastrtps_comp_shared)
+if (fastdds_comp_static AND fastdds_comp_shared)
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
- "fastrtps `static` and `shared` components are mutually exclusive.")
+ "fastdds `static` and `shared` components are mutually exclusive.")
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
return()
endif ()
-set(fastrtps_static_targets "${CMAKE_CURRENT_LIST_DIR}/fastrtps-static-targets.cmake")
-set(fastrtps_shared_targets "${CMAKE_CURRENT_LIST_DIR}/fastrtps-shared-targets.cmake")
+set(fastdds_static_targets "${CMAKE_CURRENT_LIST_DIR}/fastdds-static-targets.cmake")
+set(fastdds_shared_targets "${CMAKE_CURRENT_LIST_DIR}/fastdds-shared-targets.cmake")
-macro(fastrtps_load_targets type)
- if (NOT EXISTS "${fastrtps_${type}_targets}")
+macro(fastdds_load_targets type)
+ if (NOT EXISTS "${fastdds_${type}_targets}")
set(${CMAKE_FIND_PACKAGE_NAME}_NOT_FOUND_MESSAGE
- "fastrtps `${type}` libraries were requested but not found.")
+ "fastdds `${type}` libraries were requested but not found.")
set(${CMAKE_FIND_PACKAGE_NAME}_FOUND FALSE)
return()
endif ()
# find related dependency packages like OpenSSL
- @FASTRTPS_INSTALLER_OPT_DEPS@
- @FASTRTPS_PACKAGE_WIN32_OPT_DEPS@
+ @FASTDDS_INSTALLER_OPT_DEPS@
+ @FASTDDS_PACKAGE_WIN32_OPT_DEPS@
- include("${fastrtps_${type}_targets}")
+ include("${fastdds_${type}_targets}")
endmacro()
-if (fastrtps_comp_static)
- fastrtps_load_targets(static)
-elseif (fastrtps_comp_shared)
- fastrtps_load_targets(shared)
-elseif (DEFINED fastrtps_SHARED_LIBS AND fastrtps_SHARED_LIBS)
- fastrtps_load_targets(shared)
-elseif (DEFINED fastrtps_SHARED_LIBS AND NOT fastrtps_SHARED_LIBS)
- fastrtps_load_targets(static)
+if (fastdds_comp_static)
+ fastdds_load_targets(static)
+elseif (fastdds_comp_shared)
+ fastdds_load_targets(shared)
+elseif (DEFINED fastdds_SHARED_LIBS AND fastdds_SHARED_LIBS)
+ fastdds_load_targets(shared)
+elseif (DEFINED fastdds_SHARED_LIBS AND NOT fastdds_SHARED_LIBS)
+ fastdds_load_targets(static)
elseif (BUILD_SHARED_LIBS)
- if (EXISTS "${fastrtps_shared_targets}")
- fastrtps_load_targets(shared)
+ if (EXISTS "${fastdds_shared_targets}")
+ fastdds_load_targets(shared)
else ()
- fastrtps_load_targets(static)
+ fastdds_load_targets(static)
endif ()
else ()
- if (EXISTS "${fastrtps_static_targets}")
- fastrtps_load_targets(static)
+ if (EXISTS "${fastdds_static_targets}")
+ fastdds_load_targets(static)
else ()
- fastrtps_load_targets(shared)
+ fastdds_load_targets(shared)
endif ()
endif ()
diff --git a/cmake/packaging/windows/fastdds-config.cmake b/cmake/packaging/windows/fastdds-config.cmake
new file mode 100644
index 00000000000..f8b17d560d1
--- /dev/null
+++ b/cmake/packaging/windows/fastdds-config.cmake
@@ -0,0 +1,23 @@
+# Copyright 2016 Proyectos y Sistemas de Mantenimiento SL (eProsima).
+#
+# Licensed under the Apache License, Version 2.0 (the "License");
+# you may not use this file except in compliance with the License.
+# You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS,
+# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+# See the License for the specific language governing permissions and
+# limitations under the License.
+
+if(MSVC_VERSION LESS_EQUAL 1900)
+ message(FATAL_ERROR "Visual Studio version ${MSVC_VERSION} is no longer supported")
+else()
+ if(CMAKE_CL_64)
+ include("${CMAKE_CURRENT_LIST_DIR}/../share/fastdds-x64Win64VS2019/cmake/fastdds-config.cmake")
+ else()
+ include("${CMAKE_CURRENT_LIST_DIR}/../share/fastdds-i86Win32VS2019/cmake/fastdds-config.cmake")
+ endif()
+endif()
diff --git a/cmake/packaging/windows/fastrtps.manifest.in b/cmake/packaging/windows/fastdds.manifest.in
similarity index 100%
rename from cmake/packaging/windows/fastrtps.manifest.in
rename to cmake/packaging/windows/fastdds.manifest.in
diff --git a/cmake/packaging/windows/fastrtps-config.cmake b/cmake/packaging/windows/fastrtps-config.cmake
deleted file mode 100644
index ee4a8b9ad95..00000000000
--- a/cmake/packaging/windows/fastrtps-config.cmake
+++ /dev/null
@@ -1,23 +0,0 @@
-# Copyright 2016 Proyectos y Sistemas de Mantenimiento SL (eProsima).
-#
-# Licensed under the Apache License, Version 2.0 (the "License");
-# you may not use this file except in compliance with the License.
-# You may obtain a copy of the License at
-#
-# http://www.apache.org/licenses/LICENSE-2.0
-#
-# Unless required by applicable law or agreed to in writing, software
-# distributed under the License is distributed on an "AS IS" BASIS,
-# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-# See the License for the specific language governing permissions and
-# limitations under the License.
-
-if(MSVC_VERSION LESS_EQUAL 1900)
- message(FATAL_ERROR "Visual Studio version ${MSVC_VERSION} is no longer supported")
-else()
- if(CMAKE_CL_64)
- include("${CMAKE_CURRENT_LIST_DIR}/../share/fastrtps-x64Win64VS2019/cmake/fastrtps-config.cmake")
- else()
- include("${CMAKE_CURRENT_LIST_DIR}/../share/fastrtps-i86Win32VS2019/cmake/fastrtps-config.cmake")
- endif()
-endif()
diff --git a/colcon.pkg b/colcon.pkg
index d71654b9523..8e78ca24b51 100644
--- a/colcon.pkg
+++ b/colcon.pkg
@@ -1,5 +1,5 @@
{
- "name": "fastrtps",
+ "name": "fastdds",
"type": "cmake",
"dependencies" : ["fastcdr", "FOONATHAN_MEMORY", "foonathan_memory_vendor", "googletest-distribution"]
}
diff --git a/doc/README.html.in b/doc/README.html.in
deleted file mode 100644
index 95c615285c0..00000000000
--- a/doc/README.html.in
+++ /dev/null
@@ -1,1273 +0,0 @@
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- |
- eProsima
Plaza de la Encina 10-11
Nucleo 4, 2Βͺ Planta
28760 Tres Cantos (Madrid)
- |
-
- 
-
- Fast DDS v@PROJECT_VERSION@ |
-
- Email: support@eprosima.com
Phone: +34 91 804 34 48
www.eprosima.com
- |
-
-
-
-
-Available documentation:
-
-
-Local:
-
-
-
-
Online (updated frequently):
-
-
-
-
-
Copyright© 2019 eProsima. All rights reserved.
-
This copy of eProsima Fast DDS is licensed to you under the terms described in the LICENSE file included in this distribution.
-
-
diff --git a/doc/design/intra-process.md b/doc/design/intra-process.md
deleted file mode 100644
index 89ee6c7ea93..00000000000
--- a/doc/design/intra-process.md
+++ /dev/null
@@ -1,93 +0,0 @@
-# Intra-process delivery
-
-Several requirements, each with a section.
-
-## Identifying local endpoints
-Endpoints on the same process have the same content on the first 8 octets of their GUID prefix.
-
-### GUID_t refactor
-* Provide methods `is_builtin()`, `is_on_same_process_as(other_guid)` and `is_on_same_host_as(other_guid)`
-* Consider other improvements
- * Split Guid.h into three headers (guid, prefix and entity_id)
- * Converting EntityId_t to uint32_t
- * Use a union on GuidPrefix_t to efficiently compare parts of it
-
-### Getting pointers to local endpoints
-* Add methods on RTPSDomain to return a pointer to reader/writer given its guid
-* Should be aware of builtin endpoints
-
-## Intra-process reception
-The processing of new data on the subscribers is performed by the thread writing the data.
-This thread is in charge of copying the `CacheChange_t` into the `ReaderHistory` and calling `NotifyChanges()`.
-This decision was taken to maintain consistence with how currently operate the reception threads coming from transport
-layer.
-
-User's documentation should make clear any user's listener registered to be informed about new changes implies having
-blocked both the transport's reception threads and threads which write data.
-Also should explain there is another mechanism to read samples, using the function `wait_for_unread_samples()` from the
-user's thread and then taking/reading them.
-
-Current Reader API will be used by local writers to deliver data. The local writer will call `processDataMsg` directly.
-
-## Readers: management of local writers
-When matching a writer, the reader should check if it is on the same process.
-
-**Considerations at destruction time**
-
-Until now a reader was safe to be destructed because we are sure that no thread will access it. This is possible because:
-
-* All events which use the reader were destructed first. Then the event thread will never access the reader.
-* The reader was deregistered from the `ReceiverResource` objects. Then any reception thread will never access the
-reader.
-
-Now a reader can be accessed by a writer from the local process. But it was accessed if there was a match with the
-writer using discovery. Therefore, we should make sure there will be an unmatch with the writer using discovery before
-the reader is destructed. And this unmatch will be instantly because the EDP builtin endpoints will use intraprocess
-mechanism.
-
-### StatefulReader
-No output traffic to local writers should be performed.
-* Changes on WriterProxy
- * `remote_locators_shrinked` should return an empty vector for local writers
- * Timed event `heartbeat response` should never be started for local writers
- * Timed event `initial acknack` should directly call `process_acknack` on the local writer
-
-## Writers: management of local readers
-When matching a reader, the writer should check if it is on the same process.
-* No output traffic to local readers should be performed.
-* Samples are sent to local readers using `processDataMsg`.
-* When a local reader is matched, and transient_local durability is used, the reader should automatically receive data
-with `processDataMsg`.
-
-### StatelessWriter
-* On ReaderLocator::start, no locators should be added when the reader is local
-
-### StatefulWriter
-* Samples sent to local readers are automatically acknowledged
-* Gaps sent to local readers should directly call `processGapMsg`
-* Heartbeats sent to local readers should directly call `processHeartbeatMsg`
-* Timed events should never be started for local readers, except for an `initial heartbeat`
-
-## Discovery process
-
-### Participant discovery (PDP)
-In order to keep the sepparation of domains while on the same process, we will leave participant discovery to the standard mechanism.
-No intraprocess delivery will be used for builtin PDP readers and writers.
-
-### Endpoint discovery (EDP)
-We will leave endpoint discovery to the standard mechanism, but builtin endpoints will use the new mechanism to
-send/receive `WriterProxyData` and `ReaderProxyData` to/from the ones on the local process.
-
-## Additional considerations
-
-### Security
-If we rely on the comparison of the GUID to identify endpoints on the same process, those belonging to a secured participant will not be taken into account, as in that case the GUID is recalculated using a hash of the whole participant GUID.
-
-### Liveliness
-No changes are necessary for the liveliness assertion mechanism, except that manual_by_topic assertions should directly call `processHeartbeatMsg` on local readers.
-
-### Side effects
-
-* This design isolates all message traffic from the wire, that is, tools like **wiresharkβ’** will become useless. Given that most of our customers actually run intraprocess code, and report their issues using **wiresharkβ’** traces, these changes will create a support nightmare. A workaround may be to supply a flag to inhibits the intraprocess behavior for debugging purposes, stating clearly, that it should be turn off during performance test.
-
-* Once a shared memory transport is developed for interprocess purposes, an intraprocess mechanism would be pointless. That's because the trade off between speed gain and source complexity would be very expensive. From memory consumption point of view using an interprocess discovery database would yield more benefits that having per-process discovery databases.
diff --git a/doc/design/shared-memory-transport/interprocess_shared_mem.md b/doc/design/shared-memory-transport/interprocess_shared_mem.md
deleted file mode 100644
index 1f650474a1e..00000000000
--- a/doc/design/shared-memory-transport/interprocess_shared_mem.md
+++ /dev/null
@@ -1,105 +0,0 @@
-# Interprocess Shared Memory model
-
-## Overview
-
-This document describes a model for interprocess shared memory communication of software components interchanging data messages. The objective of the model is to provide a shared memory based transport layer suitable for a Real-time Publish-Subscribe DDS (Data Distribution Service).
-
-## Context
-
-eProsima has received commercial proposals to implement a shared memory transport as an improvement of its FastRPTS product. The goals listed in this document are extracted from the customers proposals.
-
-### Improvements over the standard network transports
-
-* Reduce OS Kernel calls: This is unavoidable for transports like UDP / TCP (even with the loopback interface).
-* Large message support: Network stacks needs to fragment large packets.
-* Avoid data serialization / deserialization process: This is not possible in heterogeneous networks, but is possible in shared memory interprocess communication.
-* Reduce memory copies: A buffer can be shared directly with several readers without additional copies.
-
-### Objectives
-
-* Increase the communications performance of processes in the same machine.
-* Create a portable shared memory library (Windows / Linux / MacOS).
-* Documentation.
-* Tests
-* Examples / Tutorials.
-
-## Architecture
-
-### Design concepts
-
-* **Segment**: Is a block of shared memory of fixed size that can be accessed from different processes. Shared memory segments have a global name so any process who knows the name can open the segment and map it in its address space.
-
-* **SegmentId**: SegmentIds are names that uniquely identify shared memory segments, these names are 16 characters UUIDs.
-
-* **Shared memory buffer**: Is a buffer allocated in the shared memory segment.
-
-* **Buffer descriptor**: Shared memory buffers can be referenced by buffers descriptors, these descriptors act like pointers to a buffer that can be copied between processes with a minimum cost. A descriptor contains the SegmentId and the offset to the data from the base of the segment.
-
-* **Shared memory port**: Is a communication channel identified by a port_id(uint32_t number). Through this channel, buffer descriptors are sent to other processes. It has a ring-buffer, in shared memory, where descriptors are stored. The same port can by opened by several processes for reading and writing operations. Multiple listeners can be registered in a port to be notified when descriptors are pushed to the ring-buffer. Multiple data producers can push descriptors to a port. The port contains an atomic counter with the number of listeners registered on it, each position in the ring-buffer has also a counter initialized to the number of listeners, as listeners read the descriptor, decrement the counter, so the ring-buffer position will be considered free when the counter is zero. The port also has an interprocess condition variable where the listeners will wait for incoming descriptors.
-
-* **Listener**: Listeners listen to descriptors pushed to a port. The Listener provides an interface for the application to wait and access to the data referenced by the descriptors. When a consumer pops a descriptor from the port listener, look at the descriptor's SegmentId field to open the origin shared memory segment (if not already opened in this process), once the origin segment is mapped locally, the consumer is able to access the data using the offset field contained in the descriptor.
-
-* **SharedMemoryManager**: Applications instantiate this object in order to access the shared memory resources described above. At least one per process memory manager is required. The manager provides functionality for the application to create shared memory segments, alloc data buffers in the segments, push buffer descriptors to shared memory ports and create listeners associated to a port.
-
-### Example scenario
-
-
-Let's study the above example. There are three processes with a SharedMemManager per process, every process creates its own shared memory segment intended to store the buffers that will be shared with other processes.
-
-P1, P2 and P3 processes are participants in a RTPS-DDS environment. Discovery of participants is done by using multicast, so we have selected shared memory port0 as "multicast" port for discovery, therefore, first thing all participants do is to open the shared memory port0. A listener attached to port0 is created too, by every participant, to read the incoming descriptors.
-
-Each participant opens a port to receive unicast messages, ports 1, 2 and 3 respectively, and create listeners associated to those ports.
-
-The first message the participants send is the multicast discovery message: "I'm here, and I am listening on portN". So they alloc a buffer in its local segment, write that information to the buffer and push the buffer's descriptor through the port0. Observe how port0's ring-buffer store the descriptors to Data1a(P1), Data2a(P2), Data3a(P3) after all processes have pushed their discovery descriptors.
-
-After the discovery phase, participants know the other participants and their "unicast" ports so they can send messages to specific participants by pushing to the participant's unicast port.
-
-Finally, let's observe how P1 is sharing Data1c with P2 and P3, this is done by pushing the buffer descriptor to P2 and P3 unicast ports. This way one shared memory buffer can be shared with several processes without making any copy of the buffer (just copy the descriptors). This is an important improvement with respect to transports like UDP and TCP.
-
-### Design considerations
-
-* **Minimize global interprocess locks**: Interprocess locks are dangerous because, in the case one of the involved processes crashes while holding an interprocess lock, all the collaborating processes could be affected. In this design, pushing data to a port and reading data from the port are lock-free operations. For performance reasons waiting for data on a port, when the port is empty, requires interprocess lock mecanishms like mutexes and condition variables. This is specially dangerous in multicast ports because if one listener crashes while waiting this could block the port for the rest of the listeners. More complex design features could be added to make the library fault-tolerance, but it will possibly be at a cost of losing performance.
-
-* **Scalable number of processes**: Every process creates its own shared memory segments to store the locally generated messages. This is more scalable than having a global segment shared between all the involved processes.
-
-* **Per application / process customizable memory usage**: Again, a local shared memory segment allows to adapt the size of the segments to the requirements of the application. Imagine for example an application sending two types of data: Video and status info. It could create a big segment to store video frames, and a small segment for the status messages.
-
-### Future improvements
-
-* **Fault tolerance**: As stated in the design considerations, the possibility of a process crashing holding interprocess resources is real. Implementing fault tolerance for these cases is not an easy task. Timeouts, keep alive checks and garbage collectors are some of the things that could be added to the initial design in order to achieve fault tolerance. This will be considered in future revisions.
-
-### Mapping the design to FastRTPS
-
-#### Transport Layer
-
-* **Locators**: LOCATOR_KIND_SHM Is defined to identify shared memory transport endpoints. Locator_t fields are filled in this way:
- * kind: 16 (Is the RTPS vendor-specific range).
- * port: The locator's port contains the shared memory port_id.
- * address: The whole address is set to 0 except for the first byte that is used to mark unicast (address[0]='U') or multicast (address[0]='M').
-
-* **SharedMemTransportDescriptor**: The following values can be customized:
- * segment_size: Size of the shared memory segment reserved by the transport.
- * port_queue_capacity: Size, in number of messages, of the shared memory port message queue.
- * port_overflow_policy: DISCARD or FAIL.
- * segment_overflow_policy: DISCARD or FAIL
- * max_message_size: By default max_message_size will be the segment_size, but is possible to specify a value <= segment_size. In that case fragmentation could occur.
-
-* **Default metatraffic multicast locator**: One locator, the port will be selected by the participant (will be the same as in the RTPS standard for UDP).
-
-* **Default metatraffic unicast locator**: One locator, the port will be selected by the participant (default port_id will be the same as in the RTPS standard for UDP).
-
-* **Default output locator**: There will be no default output locator.
-
-* **OpenInputChannel**: A SharedMemChannelResource instance will be created. An opened channels vector is maintained, if the same input locator is opened several times the channel instance is reused.
-
-* **OpenOutputChannel**: There will be only one SharedMemSenderResource instance per transport instance, an unordered_map of opened ports will be maintained by the SharedMemSenderResource object in order to match the destination locators to the shared memory ports.
-
-## Class design
-
-
-#### RTPS Layer
-
-In FastRTPS transports are associated to participants, so the new SHM transport can used, by adding an instance of a SharedMemTransportDescriptor class to the list of participant's user transports.
-So there is a shared memory segment per participant that will be shared by all participant's publishers.
-
-Transport selection: As RTPSParticipant is able to have multiple transports, a transport selection mecanishm is necessary when communicating with other participants reachable by several transports. The defined behaviour here is: If the participants involved are in the same host and both have SHM transport configured, then SHM transport is selected for all communications between those participants.
diff --git a/doc/design/shared-memory-transport/interprocess_shared_mem1.png b/doc/design/shared-memory-transport/interprocess_shared_mem1.png
deleted file mode 100644
index 3187e9ad534..00000000000
Binary files a/doc/design/shared-memory-transport/interprocess_shared_mem1.png and /dev/null differ
diff --git a/doc/design/shared-memory-transport/interprocess_shared_mem2.plantuml b/doc/design/shared-memory-transport/interprocess_shared_mem2.plantuml
deleted file mode 100644
index 427a646dfc0..00000000000
--- a/doc/design/shared-memory-transport/interprocess_shared_mem2.plantuml
+++ /dev/null
@@ -1,68 +0,0 @@
-```plantuml
-@startuml
-
-hide empty members
-
-!define struct(x) class x << (S,CadetBlue) >>
-
-class SharedMemTransport {
- ..Channel handling..
- +OpenOutputChannel()
- +OpenInputChannel()
- +Send()
- ..
- -input_channels_
-}
-
-struct(SharedMemTransportDescriptor) {
- ..Interface implementation..
- +min_send_buffer_size()
- +max_message_size()
- ..Additional configuration..
- +segment_size
- +port_queue_capacity
- +port_overflow_policy
-}
-
-class ChannelResource {
-
-}
-
-class SharedMemChannelResource {
- +Receive()
-}
-
-class SenderResource {
-}
-
-class SharedMemSenderResource {
- -locators_ports_map
-}
-
-class SharedMemManager {
- +create_segment()
- +open_port()
-}
-
-class SharedMemManager::Port {
- +push()
- +create_listener()
-}
-
-class SharedMemManager::Listener {
- +pop()
-}
-
-TransportInterface ()-- SharedMemTransport
-TransportDescriptorInterface ()-- SharedMemTransportDescriptor
-ChannelResource <|-- SharedMemChannelResource
-SharedMemTransport o-- SharedMemManager
-SharedMemTransport "1" *-- "n" SharedMemChannelResource
-SenderResource <|-- SharedMemSenderResource
-SharedMemTransport "1" *-- "1" SharedMemSenderResource
-SharedMemChannelResource "1" *-- "1" SharedMemManager::Listener : listen on
-SharedMemManager::Listener "1" o-- "1" SharedMemManager::Port
-SharedMemSenderResource "1" *-- "n" SharedMemManager::Port : send to
-
-@enduml
-```
\ No newline at end of file
diff --git a/doc/design/shared-memory-transport/interprocess_shared_mem2.png b/doc/design/shared-memory-transport/interprocess_shared_mem2.png
deleted file mode 100644
index 67b022e7a30..00000000000
Binary files a/doc/design/shared-memory-transport/interprocess_shared_mem2.png and /dev/null differ
diff --git a/doc/pdf/FASTRTPSGEN - User Manual.odt b/doc/pdf/FASTRTPSGEN - User Manual.odt
deleted file mode 100644
index 704aeff52da..00000000000
Binary files a/doc/pdf/FASTRTPSGEN - User Manual.odt and /dev/null differ
diff --git a/doc/pdf/Fast RTPS - Installation Manual.odt b/doc/pdf/Fast RTPS - Installation Manual.odt
deleted file mode 100644
index 5367442e0e7..00000000000
Binary files a/doc/pdf/Fast RTPS - Installation Manual.odt and /dev/null differ
diff --git a/doc/pdf/Fast RTPS - Latency Test.odt b/doc/pdf/Fast RTPS - Latency Test.odt
deleted file mode 100644
index b8de45281e6..00000000000
Binary files a/doc/pdf/Fast RTPS - Latency Test.odt and /dev/null differ
diff --git a/doc/pdf/Fast RTPS - Throughput Test.odt b/doc/pdf/Fast RTPS - Throughput Test.odt
deleted file mode 100644
index 0a1585ea441..00000000000
Binary files a/doc/pdf/Fast RTPS - Throughput Test.odt and /dev/null differ
diff --git a/doc/pdf/Fast RTPS - User Manual.odt b/doc/pdf/Fast RTPS - User Manual.odt
deleted file mode 100644
index 9f4a3ff045b..00000000000
Binary files a/doc/pdf/Fast RTPS - User Manual.odt and /dev/null differ
diff --git a/doc/proposals/shared-memory-transport/sony/PubSub_overview.png b/doc/proposals/shared-memory-transport/sony/PubSub_overview.png
deleted file mode 100755
index cfc2da4d018..00000000000
Binary files a/doc/proposals/shared-memory-transport/sony/PubSub_overview.png and /dev/null differ
diff --git a/doc/proposals/shared-memory-transport/sony/RPC_overview.png b/doc/proposals/shared-memory-transport/sony/RPC_overview.png
deleted file mode 100755
index d25009c43da..00000000000
Binary files a/doc/proposals/shared-memory-transport/sony/RPC_overview.png and /dev/null differ
diff --git a/doc/proposals/shared-memory-transport/sony/improvement.png b/doc/proposals/shared-memory-transport/sony/improvement.png
deleted file mode 100755
index b913dcdbf2d..00000000000
Binary files a/doc/proposals/shared-memory-transport/sony/improvement.png and /dev/null differ
diff --git a/doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md b/doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
deleted file mode 100755
index 6bce5cff89e..00000000000
--- a/doc/proposals/shared-memory-transport/sony/ms1_rtps_shared_memory_transport.md
+++ /dev/null
@@ -1,127 +0,0 @@
-# Overview
-
-DDSi-RTPS(Real-Time Publish-Subscribe) is the **protocol** that enable to support vendor implementation. And RTPS specifies implementaion and message packet format and other stuff as well. On this proposal, it will descibe how we could integrate **shared memory as transport** for RTPS layer based on.
-
-# Objective
-
-Implement a shared Memory transport using the current Fast-RTPS transport API & Architecture: The transport will be used as any other transport (including serialization and RTPS encapsulation). This approach is used in other DDS implementations such as commercial release for OpenSplice and RTI Connext DDS. This is mostly related to ROS2 RMW transport, but it can be used in any DDS application or product.
-
-# Requirements
-
-- Multi-Platform support (Windows, Linux and MacOS) along with ROS2.
-- Design and Architecture Description
-- Source Code [Fast-RTPS](https://github.com/eProsima/Fast-RTPS)
-- Documents for user manual and tutorials.
-- ROS2/RMW compatible interface (do not break ROS2 userland)
-- Latency/Bandwidth improvement results.
-- Intra/Inter-Process Communication
-
-# Architecture / Design
-
-## Interoperability
-
-There is no gurantee that the whole system is constructed with eProsima Fast-RTPS, so multiple DDS implementaions may be used in a distributed system.
-To keep the interoperability between different vendor DDS implementations, the shared memory transport feature has to be implemented with the following:
-
-- All communications must take place using RTPS Messages.
-- All implementations must implement the RTPS Message Receiver.
-- Simple Participant and Endpoint Discovery Protocols.
-
-## Discovery
-
-Participant and Endpoint Discovery(PDP, EDP such as metatrrafic transmittion) will be kept as is in the current code, since this negotiation does not require shared memory use cases (all of the RTPS protocol stays put).
-
-## Memory Management
-
-- Dynamic Configuration
-
- Shared memory transport should be dynamically configured when necessary, that is, when the reader exists on the same host system than the writer. This is mandatory to reduce unnecessary message passing via shared memory.
-
- This can be detected using the GuidPrefix_t information in the locator, which includes vendor id, host id, process id and participant id.
-
- ```
- struct RTPS_DllAPI GuidPrefix_t
- ```
-
-- Lifecycle
-
- Shared memory lifecycle is managed by the writer corresponding to HistoryCache more likely QoS setting.
-
-- Owner
-
- Shared memory is owned by the writer. The writer is responsible of managing the shared memory (creation and removal) according to the aforementioned lifecycle.
-
-- Version
-
- Versioning must be used to check if the implementation supports the shared memory feature or not.
-
-## Shared Memory Framework
-
-Since this whole project is targeted to be multi-platform, it is mandatory not to use system dependent shared memory frameworks or primitives.
-
-- C/C++ implementation
- - Primitive baseline implementation, can be used for multi-platform.
- - But most parts need to be implemented by our own.
- - Also good affinity to intra-process, just use std::shared_ptr.
-- POSIX IPC shared memory (shm_open)
- - This is only for Unix system, so not good affinity for Windows/Mac.
-- **boost::interprocess**
- - Surely multi-platform, this is generic and up-to-date interfaces.
- - Generic shared memory interface
- - Emulation layer available for windows and system v(xsi) if necessary.
- - Memory mapped file (this can be useful to use ramfs to refresh system restart or reboot)
- - Shared memory range can be truncated dynamically.
- - Container mapping with allocator
- - File locking (this could be useful to exclude access to the memory mapped shared memory)
- - Writer has read_write mode and reader only has read_only mode.
- - ***But cannot be extremly optimized via system calls, such as hugetlb to reduce TLB miss hit and pagefaults.***
-
-
-## Event Notification
-
-Writer needs to notify right after the shared memory is ready to be read on reader side. Then reader will be notified that data is ready to read out.
-
-- RTPS extensible message
- - Submessages with ID's 0x80 to 0xff (inclusive) are vendor-specific
- - But probably we should avoid sending messages via network.
-- **boost::interprocess**
- - Condition: after data is set by writer, notify the subscribers via condition variable on shared memory (named under topic name?).
- - Semaphore: after data is set by writer, post to notify the subscribers via semaphore on shared memory. Can be used to control the number of subscribers to read via wait API (named under topic name?).
-
-## Security
-
-- Encryption / Decryption:
- - Shared memory will be used as transport only, so encrypted data will be stored on shared memory. Therefore, this does not affect anything.
-- Access Permission:
- - Can we support access permission? Like file system based access permission? This needs to be considered.
- - Since security implementation is different among platforms, boost::interprocess does not try to standardize the access permission control. This is responsibility of the implementation.
-
-## Quality of Service
-
-Since this is just a new implementation of the transport layer for shared memory, where all the rest of the RTPS protocol stays put, we expect full compatibility of configuration with Fast-RTPS.
-
-Nevertheless, this needs to be further considered during the detailed design and implementation.
-
-# Considerations
-
-## Intra Process Communication
-
-There is an intra-process communication feature in ROS2 rclcpp and rcl layer (basically zero-copy based). This has nothing to do with DDS implementation, but needs to be considered to ensure this feature doesn't break when implementing the DDS shared memory transport. Refer to [Intra-Process-Communication](https://index.ros.org//doc/ros2/Tutorials/Intra-Process-Communication/)
-
-Intra-process communication does not support QoS specification, e.g) RMW_QOS_POLICY_HISTORY_KEEP_ALL, !RMW_QOS_POLICY_DURABILITY_VOLATILE is not supported.
-
-Intra-process communication uses a ring buffer that is internally implemented [mapped_ring_buffer.hpp](https://github.com/ros2/rclcpp/blob/master/rclcpp/include/rclcpp/mapped_ring_buffer.hpp).
-
-**this implementataion will stay on rclcpp for other implementations, but will be decricated for eProsima Fast-RTPS use-cases basically.**
-
-## Container Boundary
-
-Using containers basically means to divide the user space into independent sections, so shared memory should not be used beyond the container boundary.
-
-This can be actually done just checking IP addresses to see if both participants are in the same host or not. So we don't expect addtional requirements, it just appears to be another network interface.
-
-# Reference
-
-[ROSConJP 2019 Lightning Talk Presentation](https://discourse.ros.org/uploads/short-url/1SbbxgRCiM6NH2BuSCqNAe0aogx.pdf)
-[Boost.Interprocess](https://www.boost.org/doc/libs/1_71_0/doc/html/interprocess.html)
-
diff --git a/doc/proposals/shared-memory-transport/sony/ms2_rmw_shared_memory_data_share_sony.md b/doc/proposals/shared-memory-transport/sony/ms2_rmw_shared_memory_data_share_sony.md
deleted file mode 100755
index f5c9770155d..00000000000
--- a/doc/proposals/shared-memory-transport/sony/ms2_rmw_shared_memory_data_share_sony.md
+++ /dev/null
@@ -1,87 +0,0 @@
-# Overview
-
-Sony has already done implementation using internal shared memory light framework to connect rmw layer, so that ROS2 applicatoin can use the shared memory publisher/subscriber framework without notice. This is the same target for milestone-2, so this documentation describe about the history and feasibilities, and also basic design for shared memory data sharing in linux system.
-
-# Background
-
-- We need to deal with a large amount of data for recognitions, robotics, intelligent processes like agent device. The data has to be shared among a lot of framework and process spaces, otherwise copy in/out system space overhead will stress the system resources. especially embedded devices, this could be fatal issue.
-- It is impossible to complete the requirement with single process even if that is the embedded consumer devices. Data shall be shared in the host system efficiently so that application can use the data without concern. Besides data size is getting bigger and bigger such as 4K, 8K images, ToF, Lidar, Radar, PointCloud and so on. We surely need more band width/high latency data sharing against these situations.
-
-# Requirements
-
-### Publisher/Subscriber Architecture (N:N)
-
-
-
-Publisher: after system calls to map and create message on the filesystem, it will directly write the dat into the message. Then at the finish writing or closing file, that will be notified to the subscriber with file path.
-
-Subscriber: file path will be notified via inotify, the subscriber to get the corresponding message to open and read directly.
-
-**There will be no copy insluding user application or framework itself**
-
-### Remote Procedure Call Support (1:1 asynchronous, such as rosservice)
-
-
-
-Unique ID assigned for each message, so easy to recognize whoβs message.
-
-- Perfectly Copyless Data Sharing
-- Low Latency and High Throughput
-- Message Lifecycle and Timestamp support
-- Data Access Control via Filesystem
-- Storage supported as backend (user flexibility)
-
-# Design
-
-## Platform
-
-Linux 2.6.13 or later (technically the platform supports [inotify](http://man7.org/linux/man-pages/man7/inotify.7.html))
-
-## Data Channel
-
-Basically in-memory file system such as ramfs or tmpfs. but this is not a limitation or constraints, user can choose the backend file system to specify the root directory. ramfs and tmpfs is actually memory storage, but it can keep the file on the filesystem as long as system running. this would be also good, once the system reboots it will refresh the entire cache data, we can restart as clean.
-
-Taking advantage of linux interfaces such as map/unmap to assign the physical pages into the user process space, no additional overhead or stack will be provided from this framework.
-
-## Signal and Event Notification
-
-from our experience and benchmark on embedded linux system, [inotify](http://man7.org/linux/man-pages/man7/inotify.7.html) came up the candidate number 1. inotify is also provied by linux kernel and it allows us to notify events on filesystem and what kind of events and what file is actually changed.(written, closed or opened etc.) this is really simple linux kernel interface and also support message queue order guranteed by linux kernel.
-
-## Access Permission Control
-
-since this framework is constructed on filesystem based storage, we can control access permission just like we do with normal files and user/group permission control. without certain group or access permission, user cannot even see the files or any activities by this framework.
-
-## Datatype / Serialization
-
-Do not serialize data into the shared memory with publish/subscribe. So user application needs to be aware before to write/read the binary data fits in the certain structure.
-
-## Remarkable Features (Only Related)
-
-- Configurable parameters for each topic
- root file path and ring buffer length to keep for each topic shall be predefined.
-- Ring Buffer / File Mapped Shared Memory
- Ring Buffer is controlled by framework, e.g) entries of single topic.
-- Retain Memory
- once the file is mapped into physical page, it will never unmapped unless it is necessary.
- this will reduce the huge system time via system calls.
-- Huge TLB
- also reduce system time for cache miss, pagefaults and tlb miss hit.
-
-# Feasibilities
-
-With Sony internal framework and rmw_sony_cpp to connect the implementation to ROS2 frontend, there is a huge performance improvemnent that we have taking advantage of shared memory.
-
-
-
-of course this is only prototype and Non-DDS implementation which means in general there is not a lot of processes that is required with DDS implementation. But even anticipated value expectation in prototype, there is an improvement as followings.
-
-
-
-- Publisher:Subscriber = 1:1
-- Serializer is [Fast-CDR](https://github.com/eProsima/Fast-CDR)
-- Ubuntu 18.04 ROS Dashing
-- Skylake PC
-
-# Note
-
-This is just for sharing primitives, but we can work on this feature more generic way and keep the improvement as it is.
diff --git a/doc/proposals/shared-memory-transport/sony/rmw_sony_cpp.png b/doc/proposals/shared-memory-transport/sony/rmw_sony_cpp.png
deleted file mode 100755
index eda23ff7ecd..00000000000
Binary files a/doc/proposals/shared-memory-transport/sony/rmw_sony_cpp.png and /dev/null differ
diff --git a/examples/CMakeLists.txt b/examples/CMakeLists.txt
index 88766a3b3ff..d63b96f986c 100644
--- a/examples/CMakeLists.txt
+++ b/examples/CMakeLists.txt
@@ -12,6 +12,6 @@
# See the License for the specific language governing permissions and
# limitations under the License.
-set(fastrtps_FOUND TRUE)
+set(fastdds_FOUND TRUE)
add_subdirectory(cpp/dds)
add_subdirectory(cpp/rtps)
diff --git a/examples/cpp/dds/AdvancedConfigurationExample/AdvancedConfiguration.cxx b/examples/cpp/dds/AdvancedConfigurationExample/AdvancedConfiguration.cxx
deleted file mode 100644
index f423c3c9cc9..00000000000
--- a/examples/cpp/dds/AdvancedConfigurationExample/AdvancedConfiguration.cxx
+++ /dev/null
@@ -1,214 +0,0 @@
-// Copyright 2016 Proyectos y Sistemas de Mantenimiento SL (eProsima).
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-/*!
- * @file AdvancedConfiguration.cpp
- * This source file contains the implementation of the described types in the IDL file.
- *
- * This file was generated by the tool fastddsgen.
- */
-
-#ifdef _WIN32
-// Remove linker warning LNK4221 on Visual Studio
-namespace {
-char dummy;
-} // namespace
-#endif // _WIN32
-
-#include "AdvancedConfiguration.h"
-
-#if FASTCDR_VERSION_MAJOR > 1
-
-#include
-
-
-#include
-using namespace eprosima::fastcdr::exception;
-
-#include
-
-
-
-
-
-
-AdvancedConfiguration::AdvancedConfiguration()
-{
-}
-
-AdvancedConfiguration::~AdvancedConfiguration()
-{
-}
-
-AdvancedConfiguration::AdvancedConfiguration(
- const AdvancedConfiguration& x)
-{
- m_index = x.m_index;
- m_message = x.m_message;
- m_data = x.m_data;
-}
-
-AdvancedConfiguration::AdvancedConfiguration(
- AdvancedConfiguration&& x) noexcept
-{
- m_index = x.m_index;
- m_message = std::move(x.m_message);
- m_data = std::move(x.m_data);
-}
-
-AdvancedConfiguration& AdvancedConfiguration::operator =(
- const AdvancedConfiguration& x)
-{
-
- m_index = x.m_index;
- m_message = x.m_message;
- m_data = x.m_data;
- return *this;
-}
-
-AdvancedConfiguration& AdvancedConfiguration::operator =(
- AdvancedConfiguration&& x) noexcept
-{
-
- m_index = x.m_index;
- m_message = std::move(x.m_message);
- m_data = std::move(x.m_data);
- return *this;
-}
-
-bool AdvancedConfiguration::operator ==(
- const AdvancedConfiguration& x) const
-{
- return (m_index == x.m_index &&
- m_message == x.m_message &&
- m_data == x.m_data);
-}
-
-bool AdvancedConfiguration::operator !=(
- const AdvancedConfiguration& x) const
-{
- return !(*this == x);
-}
-
-/*!
- * @brief This function sets a value in member index
- * @param _index New value for member index
- */
-void AdvancedConfiguration::index(
- uint32_t _index)
-{
- m_index = _index;
-}
-
-/*!
- * @brief This function returns the value of member index
- * @return Value of member index
- */
-uint32_t AdvancedConfiguration::index() const
-{
- return m_index;
-}
-
-/*!
- * @brief This function returns a reference to member index
- * @return Reference to member index
- */
-uint32_t& AdvancedConfiguration::index()
-{
- return m_index;
-}
-
-
-/*!
- * @brief This function copies the value in member message
- * @param _message New value to be copied in member message
- */
-void AdvancedConfiguration::message(
- const std::array& _message)
-{
- m_message = _message;
-}
-
-/*!
- * @brief This function moves the value in member message
- * @param _message New value to be moved in member message
- */
-void AdvancedConfiguration::message(
- std::array&& _message)
-{
- m_message = std::move(_message);
-}
-
-/*!
- * @brief This function returns a constant reference to member message
- * @return Constant reference to member message
- */
-const std::array& AdvancedConfiguration::message() const
-{
- return m_message;
-}
-
-/*!
- * @brief This function returns a reference to member message
- * @return Reference to member message
- */
-std::array& AdvancedConfiguration::message()
-{
- return m_message;
-}
-
-
-/*!
- * @brief This function copies the value in member data
- * @param _data New value to be copied in member data
- */
-void AdvancedConfiguration::data(
- const std::vector& _data)
-{
- m_data = _data;
-}
-
-/*!
- * @brief This function moves the value in member data
- * @param _data New value to be moved in member data
- */
-void AdvancedConfiguration::data(
- std::vector&& _data)
-{
- m_data = std::move(_data);
-}
-
-/*!
- * @brief This function returns a constant reference to member data
- * @return Constant reference to member data
- */
-const std::vector& AdvancedConfiguration::data() const
-{
- return m_data;
-}
-
-/*!
- * @brief This function returns a reference to member data
- * @return Reference to member data
- */
-std::vector& AdvancedConfiguration::data()
-{
- return m_data;
-}
-
-
-// Include auxiliary functions like for serializing/deserializing.
-#include "AdvancedConfigurationCdrAux.ipp"
-
-#endif // FASTCDR_VERSION_MAJOR > 1
diff --git a/examples/cpp/dds/AdvancedConfigurationExample/AdvancedConfiguration.h b/examples/cpp/dds/AdvancedConfigurationExample/AdvancedConfiguration.h
deleted file mode 100644
index 207a02e1cd0..00000000000
--- a/examples/cpp/dds/AdvancedConfigurationExample/AdvancedConfiguration.h
+++ /dev/null
@@ -1,225 +0,0 @@
-// Copyright 2016 Proyectos y Sistemas de Mantenimiento SL (eProsima).
-//
-// Licensed under the Apache License, Version 2.0 (the "License");
-// you may not use this file except in compliance with the License.
-// You may obtain a copy of the License at
-//
-// http://www.apache.org/licenses/LICENSE-2.0
-//
-// Unless required by applicable law or agreed to in writing, software
-// distributed under the License is distributed on an "AS IS" BASIS,
-// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
-// See the License for the specific language governing permissions and
-// limitations under the License.
-
-/*!
- * @file AdvancedConfiguration.h
- * This header file contains the declaration of the described types in the IDL file.
- *
- * This file was generated by the tool fastddsgen.
- */
-
-#include
-#include "AdvancedConfigurationv1.h"
-
-#if FASTCDR_VERSION_MAJOR > 1
-
-#ifndef _FAST_DDS_GENERATED_ADVANCEDCONFIGURATION_H_
-#define _FAST_DDS_GENERATED_ADVANCEDCONFIGURATION_H_
-
-#include
-#include
-#include
-#include