polejoe · polejoe · Mar 22, 2022 · Mar 25, 2022 · Mar 23, 2022 · Mar 23, 2022
diff --git a/.azure/templates/build-test.yml b/.azure/templates/build-test.yml
@@ -79,7 +79,7 @@ steps:
       pre-commit run --all-files
     name: run_pre_commit
   - bash: |
-      pip install gcovr --user --upgrade
+      pip install gcovr==5.0 --user --upgrade
     condition: eq(variables['coverage'], 'on')
     name: install_gcovr
   - bash: |

diff --git a/CMakeLists.txt b/CMakeLists.txt
@@ -10,7 +10,7 @@
 # SPDX-License-Identifier: EPL-2.0 OR BSD-3-Clause
 #
 cmake_minimum_required(VERSION 3.10)
-project(CycloneDDS VERSION 0.9.0 LANGUAGES C)
+project(CycloneDDS VERSION 0.9.1 LANGUAGES C)
 if(CMAKE_VERSION VERSION_LESS 3.12)
   # GENERATE_EXPORT_HEADER requires a C++ compiler up to version 3.12
   enable_language(CXX)
@@ -346,4 +346,4 @@ if(DEFINED ENV{LIB_FUZZING_ENGINE})
   add_subdirectory(fuzz)
 endif()
 
-include(CMakeCPack.cmake)
+include(CMakeCPack.cmake)
diff --git a/README.md b/README.md
@@ -4,249 +4,30 @@
 [![License](https://img.shields.io/badge/License-EPL%202.0-blue)](https://choosealicense.com/licenses/epl-2.0/)
 [![License](https://img.shields.io/badge/License-EDL%201.0-blue)](https://choosealicense.com/licenses/edl-1.0/)
 
-# Eclipse Cyclone DDS
+# This branch supports CycloneDDS over FreeRTOS-Plus-TCP stack on FreeRTOS.  
+CycloneDDS looks have support on FreeRTOS+LWIP Stack,  
+however lacking FreeRTOS-Plus-TCP Stack support  
+This change managed to add +TCP support  
+
+* base CycloneDDS version0.9.1  
+* ddsrt socket / thread ...  
+
+[Changes]  
++TCP socket  
+ddsrt header and source  
+sockaddr ifaddr  
+.init_array section  
+log sink  
+multicast/unicast peer define in xml  
+TLS-Thread_Local_Storage from FreeRTOS SW impl instread of toolchain  
+sock_waitset  
+sock fdset  
+sendmsg/recvmsg for UDP  
+dds_align from 0.10.2  
+FragmentSize for jumbo and normal  
+
+# DDS Readme refer to master readme
+Link:
+https://github.com/polejoe/cycloneDDS_RTOS/blob/master/README.md
 
-Eclipse Cyclone DDS is a very performant and robust open-source DDS implementation.  Cyclone DDS is developed completely in the open as an Eclipse IoT project
-(see [eclipse-cyclone-dds](https://projects.eclipse.org/projects/iot.cyclonedds)) with a growing list of [adopters](https://iot.eclipse.org/adopters/?#iot.cyclonedds) (if you're one of them, please add your [logo](https://github.com/EclipseFdn/iot.eclipse.org/issues/new?template=adopter_request.md)).  It is a tier-1 middleware for the Robot Operating System [ROS 2](https://docs.ros.org/en/rolling/).
 
-* [Getting Started](#getting-started)
-* [Performance](#performance)
-* [Configuration](#configuration)
-
-> Consult the [roadmap](ROADMAP.md) for a high-level overview of upcoming features.
-
-# Getting Started
-
-## Building Eclipse Cyclone DDS
-
-In order to build Cyclone DDS you need a Linux, Mac or Windows 10 machine (or, with some caveats, a *BSD, OpenIndiana or a Solaris 2.6 one) with the following installed on your host:
-
-  * C compiler (most commonly GCC on Linux, Visual Studio on Windows, Xcode on macOS);
-  * GIT version control system;
-  * [CMake](https://cmake.org/download/), version 3.10 or later;
-  * [OpenSSL](https://www.openssl.org/), preferably version 1.1 or later if you want to use TLS over
-    TCP.  You can explicitly disable it by setting ``ENABLE_SSL=NO``, which is very useful for
-    reducing the footprint or when the FindOpenSSL CMake script gives you trouble;
-  * Optionally [Bison](https://www.gnu.org/software/bison/) parser generator. A cached source is checked into the repository.
-
-If you want to play around with the parser you will need to install the bison parser generator. On Ubuntu ``apt install bison`` should do the trick for getting it installed.
-On Windows, installing chocolatey and ``choco install winflexbison3`` should get you a long way.  On macOS, ``brew install bison`` is easiest.
-
-To obtain Eclipse Cyclone DDS, do
-
-    $ git clone https://github.com/eclipse-cyclonedds/cyclonedds.git
-    $ cd cyclonedds
-    $ mkdir build
-
-Depending on whether you want to develop applications using Cyclone DDS or contribute to it you can
-follow different procedures
-
-### For application developers
-
-To build and install the required libraries needed to develop your own applications using Cyclone
-DDS requires a few simple steps. There are some small differences between Linux and macOS on the one
-hand, and Windows on the other. For Linux or macOS:
-
-    $ cd build
-    $ cmake -DCMAKE_INSTALL_PREFIX=<install-location> -DBUILD_EXAMPLES=ON ..
-    $ cmake --build .
-
-and for Windows:
-
-    $ cd build
-    $ cmake -G "<generator-name>" -DCMAKE_INSTALL_PREFIX=<install-location> -DBUILD_EXAMPLES=ON ..
-    $ cmake --build .
-
-where you should replace ``<install-location>`` by the directory under which you would like to
-install Cyclone DDS and ``<generator-name>`` by one of the ways
-CMake [generators](https://cmake.org/cmake/help/latest/manual/cmake-generators.7.html) offer for
-generating build files.  For example, "Visual Studio 15 2017 Win64" would target a 64-bit build
-using Visual Studio 2017.
-
-To install it after a successful build, do:
-
-    $ cmake --build . --target install
-
-which will copy everything to:
-
-  * ``<install-location>/lib``
-  * ``<install-location>/bin``
-  * ``<install-location>/include/ddsc``
-  * ``<install-location>/share/CycloneDDS``
-
-Depending on the installation location you may need administrator privileges.
-
-At this point you are ready to use Eclipse Cyclone DDS in your own projects.
-
-Note that the default build type is a release build with debug information included
-(RelWithDebInfo), which is generally the most convenient type of build to use from applications
-because of a good mix between performance and still being able to debug things.  If you'd rather
-have a Debug or pure Release build, set ``CMAKE_BUILD_TYPE`` accordingly.
-
-### Contributing to Eclipse Cyclone DDS
-
-We very much welcome all contributions to the project, whether that is questions, examples, bug
-fixes, enhancements or improvements to the documentation, or anything else really.  When considering
-contributing code, it might be good to know that build configurations for Travis CI and AppVeyor are
-present in the repository and that there is a test suite using CTest and CUnit that can be built
-locally if desired.  To build it, set the cmake variable ``BUILD_TESTING`` to on when configuring, e.g.:
-
-    $ cd build
-    $ cmake -DCMAKE_BUILD_TYPE=Debug -DBUILD_TESTING=ON ..
-    $ cmake --build .
-    $ ctest
-
-Such a build requires the presence of [CUnit](http://cunit.sourceforge.net/).  You can install this
-yourself, or you can choose to instead rely on the [Conan](https://conan.io) packaging system that
-the CI build infrastructure also uses.  In that case, install Conan and do:
-
-    $ conan install .. --build missing
-
-in the build directory prior to running cmake.
-
-For Windows, depending on the generator, you might also need to add switches to select the architecture
-and build type, e.g., ``conan install -s arch=x86_64 -s build_type=Debug ..`` This will automatically
-download and/or build CUnit (and, at the moment, OpenSSL).
-
-## Documentation
-
-The documentation is still rather limited, and at the moment only available in the sources (in the
-form of restructured text files in ``docs`` and Doxygen comments in the header files), or as
-a
-[PDF](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/pdf/CycloneDDS-0.1.0.pdf). The
-intent is to automate the process of building the documentation and have them available in more
-convenient formats and in the usual locations.
-
-## Building and Running the Roundtrip Example
-
-We will show you how to build and run an example program that measures latency.  The examples are
-built automatically when you build Cyclone DDS, so you don't need to follow these steps to be able
-to run the program, it is merely to illustrate the process.
-
-    $ mkdir roundtrip
-    $ cd roundtrip
-    $ cmake <install-location>/share/CycloneDDS/examples/roundtrip
-    $ cmake --build .
-
-On one terminal start the application that will be responding to pings:
-
-    $ ./RoundtripPong
-
-On another terminal, start the application that will be sending the pings:
-
-    $ ./RoundtripPing 0 0 0
-    # payloadSize: 0 | numSamples: 0 | timeOut: 0
-    # Waiting for startup jitter to stabilise
-    # Warm up complete.
-    # Latency measurements (in us)
-    #             Latency [us]                                   Write-access time [us]       Read-access time [us]
-    # Seconds     Count   median      min      99%      max      Count   median      min      Count   median      min
-        1     28065       17       16       23       87      28065        8        6      28065        1        0
-        2     28115       17       16       23       46      28115        8        6      28115        1        0
-        3     28381       17       16       22       46      28381        8        6      28381        1        0
-        4     27928       17       16       24      127      27928        8        6      27928        1        0
-        5     28427       17       16       20       47      28427        8        6      28427        1        0
-        6     27685       17       16       26       51      27685        8        6      27685        1        0
-        7     28391       17       16       23       47      28391        8        6      28391        1        0
-        8     27938       17       16       24       63      27938        8        6      27938        1        0
-        9     28242       17       16       24      132      28242        8        6      28242        1        0
-       10     28075       17       16       23       46      28075        8        6      28075        1        0
-
-The numbers above were measured on Mac running a 4.2 GHz Intel Core i7 on December 12th 2018.  From
-these numbers you can see how the roundtrip is very stable and the minimal latency is now down to 17
-micro-seconds (used to be 25 micro-seconds) on this HW.
-
-# Performance
-
-Reliable message throughput is over 1MS/s for very small samples and is roughly 90% of GbE with 100
-byte samples, and latency is about 30us when measured using [ddsperf](src/tools/ddsperf) between two
-Intel(R) Xeon(R) CPU E3-1270 V2 @ 3.50GHz (that's 2012 hardware ...) running Ubuntu 16.04, with the
-executables built on Ubuntu 18.04 using gcc 7.4.0 for a default (i.e., "RelWithDebInfo") build.
-
-<img src="https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/throughput-async-listener-rate.png" alt="Throughput" height="400"><img src="https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/latency-sync-listener.png" alt="Throughput" height="400">
-
-This is with the subscriber in listener mode, using asynchronous delivery for the throughput
-test. The configuration is a marginally tweaked out-of-the-box configuration: an increased maximum
-message size and fragment size, and an increased high-water mark for the reliability window on the
-writer side. For details, see the [scripts](examples/perfscript) directory,
-the
-[environment details](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/config.txt) and
-the
-[throughput](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/sub.log) and
-[latency](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/ping.log) data
-underlying the graphs.  These also include CPU usage ([throughput](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/throughput-async-listener-cpu.png) and [latency](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/latency-sync-listener-bwcpu.png)) and [memory usage](https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/assets/performance/20190730/throughput-async-listener-memory.png).
-
-# Configuration
-
-The out-of-the-box configuration should usually be fine, but there are a great many options that can
-be tweaked by creating an XML file with the desired settings and defining the ``CYCLONEDDS_URI`` to
-point to it.  E.g. (on Linux):
-
-    $ cat cyclonedds.xml
-    <?xml version="1.0" encoding="UTF-8" ?>
-    <CycloneDDS xmlns="https://cdds.io/config" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="https://cdds.io/config https://raw.githubusercontent.com/eclipse-cyclonedds/cyclonedds/master/etc/cyclonedds.xsd">
-        <Domain Id="any">
-            <General>
-                <Interfaces>
-                    <NetworkInterface autodetermine="true" priority="default" multicast="default" />
-                </Interfaces>
-                <AllowMulticast>default</AllowMulticast>
-                <MaxMessageSize>65500B</MaxMessageSize>
-                <FragmentSize>4000B</FragmentSize>
-            </General>
-            <Internal>
-                <Watermarks>
-                    <WhcHigh>500kB</WhcHigh>
-                </Watermarks>
-            </Internal>
-            <Tracing>
-                <Verbosity>config</Verbosity>
-                <OutputFile>stdout</OutputFile>
-            </Tracing>
-        </Domain>
-    </CycloneDDS>
-    $ export CYCLONEDDS_URI=file://$PWD/cyclonedds.xml
-
-(on Windows, one would have to use ``set CYCLONEDDS_URI=file://...`` instead.)
-
-This example shows a few things:
-
-* ``Interfaces`` can be used to override the interfaces selected by default. Members are
-  * ``NetworkInterface[@autodetermine]`` tells Cyclone DDS to autoselect the interface it deems best.
-  * ``NetworkInterface[@name]`` specifies the name of an interface to select (not shown above, alternative for autodetermine).
-  * ``NetworkInterface[@ip]`` specifies the ipv4/ipv6 address of an interface to select (not shown above, alternative for autodetermine).
-  * ``NetworkInterface[@multicast]`` specifies whether multicast should be used on this interface.
-    The default value 'default' means Cyclone DDS will check the OS reported flags of the interface
-    and enable multicast if it is supported. Use 'true' to ignore what the OS reports and enable it
-    anyway and 'false' to always disable multicast on this interface.
-  * ``NetworkInterface[@priority]`` specifies the priority of an interface. The default value (``default``)
-    means priority ``0`` for normal interfaces and ``2`` for loopback interfaces.
-* ``AllowMulticast`` configures the circumstances under which multicast will be used.  If the
-  selected interface doesn't support it, it obviously won't be used (``false``); but if it does
-  support it, the type of the network adapter determines the default value.  For a wired network, it
-  will use multicast for initial discovery as well as for data when there are multiple peers that
-  the data needs to go to (``true``); but on a WiFi network it will use it only for initial
-  discovery (``spdp``), because multicast on WiFi is very unreliable.
-* ``Verbosity`` allows control over the tracing, "config" dumps the configuration to the trace
-  output (which defaults to "cyclonedds.log").  Which interface is used, what multicast settings are
-  used, etc., is all in the trace.  Setting the verbosity to "finest" gives way more output on the
-  inner workings, and there are various other levels as well.
-* ``MaxMessageSize`` and ``FragmentSize`` control the maximum size of the RTPS messages (basically
-  the size of the UDP payload), and the size of the fragments into which very large samples get
-  split (which needs to be "a bit" less).  Large values such as these typically improve performance
-  over the (current) default values.
-* ``WhcHigh`` determines when the sender will wait for acknowledgements from the readers because it
-  has buffered too much unacknowledged data.  There is some auto-tuning, the (current) default value
-  is a bit small to get really high throughput.
-
-Background information on configuring Cyclone DDS can be found
-[here](docs/manual/config.rst) and a list of settings is
-[available](docs/manual/options.md).
-
-# Trademarks
-
-* "Eclipse Cyclone DDS" and "Cyclone DDS" are trademarks of the Eclipse Foundation.
-
-* "DDS" is a trademark of the Object Management Group, Inc.
-
-* "ROS" is a trademark of Open Source Robotics Foundation, Inc.
diff --git a/cmake/CheckHashScript.cmake b/cmake/CheckHashScript.cmake
@@ -3,11 +3,11 @@ set(CMAKE_MODULE_PATH "${CMAKE_CURRENT_LIST_DIR}/Modules")
 include(HashUtilities)
 
 check_hashes(
-    OUTVAR _test
+    _test
     HASH_FILES ${HASH_FILES}
     APPEND_FILES ${APPEND_FILES}
 )
 
 if (NOT ${_test})
     message(FATAL_ERROR "Not up to date")
-endif()
+endif()
diff --git a/cmake/Modules/FindLcov.cmake b/cmake/Modules/FindLcov.cmake
@@ -78,7 +78,7 @@ include(FindPackageHandleStandardArgs)
 find_program(LCOV_BIN lcov)
 find_program(GENINFO_BIN geninfo)
 find_program(GENHTML_BIN genhtml)
-find_package_handle_standard_args(lcov
+find_package_handle_standard_args(Lcov
 	REQUIRED_VARS LCOV_BIN GENINFO_BIN GENHTML_BIN
 )
 

diff --git a/docs/dev/xtypes_relnotes.md b/docs/dev/xtypes_relnotes.md
@@ -0,0 +1,44 @@
+# Cyclone XTypes support
+
+## Release 0.9
+
+### Type System
+
+- The following data types are not supported: map, bitset, wide-strings, char16, float128
+- For the C language binding, additionally the following types are not supported as part of a type’s key: union, sequence
+- Union types:
+    - Using bitmask type as discriminator is not supported
+    - Inheritance (7.2.2.4.5) is not supported
+    - Extensibility `mutable` for unions is not supported
+- The Dynamic Language Binding (7.5.2) is not supported (7.6.6, DynamicData and DynamicType API). Note: the Python API supports dynamic types without requiring a separate API.
+- The built-in TypeLookup service (7.6.3.3) has no support for requesting type dependencies (service operation `getTypeDependencies`, section 7.6.3.3.4.1) and replying to a request of this type.
+    - Because of this, handling `PublicationBuiltinTopicData` or `SubscriptionBuiltinTopicData` with an incomplete set of dependent types (i.e. number of entries in `dependent_typeids` is less than `dependent_typeid_count`) may result in a failure to match a reader with a writer.
+- In case a union has a default case, the C (de)serializer requires that the default case comes last because of a limitation of the IDL compiler.
+- Using the `try_construct` annotation (7.2.2.7) with a parameter other than `DISCARD` (the default) is not supported.
+- The C deserializer does not support explicit defaults for members of an aggregated type (`default` annotation)
+- External (7.3.1.2.1.4) collections element types not supported (e.g. `sequence<@external b>`)
+- Using `default_literal` (7.3.1.2.1.10) to set the default for enumerated types is not supported
+- Default extensibility is `final` rather than `appendable` to maintain backwards compatibility with DDS implementations that do not support XTypes (including Cyclone DDS versions prior to 0.9.0). The IDL compiler has command-line option to select a different default.
+
+### Type Representation
+
+- Type Object type representation
+    - Recursive types are not supported (Strongly Connected Components, 7.3.4.9)
+    - User-defined annotations (7.3.1.2.4) and `verbatim` annotations (7.3.2.5.1.1) are not included in complete type objects
+- IDL type representation
+    - Pragma declarations other than `keylist` are not supported
+    - Alternative Annotation Syntax (7.3.1.2.3) is not supported
+    - `verbatim` annotation (7.3.2.5.1.1) is not supported
+    - `ignore_literal_names` annotation (7.3.1.2.1.11) is not supported
+    - `non_serialized` annotation (7.3.1.2.1.14) is not supported
+- XML (7.3.2) and XSD (7.3.3) type representation not supported
+
+### Data Representation
+
+- Default data representation is XCDR1 for `@final` types without optional members to maintain backwards compatibility with DDS implementations that do not support XTypes (including Cyclone DDS versions prior to 0.9.0).
+
+    All other types require XCDR2: following 7.6.3.1.1 there is no need to support XCDR1 for interoperating with DDS implementations (ignoring those that only support XTypes 1.0 or 1.1, but not 1.2 or later).
+
+    The C serializer does not support PL-CDR version 1 nor optional members in PLAIN-CDR version 1.
+
+- XML data representation (7.4.4) is not supported