diff --git a/doc/README.html.in b/doc/README.html.in index 75659352b54..95c615285c0 100644 --- a/doc/README.html.in +++ b/doc/README.html.in @@ -1236,8 +1236,7 @@ qeDYVtlzxb3CYN/TnYWBLU9ef9z46sOXlcIy5NS29W/fvP/yoirVzPdAfo6bFXJOXBERUavpRCPj CGRcsajh9IybKq7s67nTHSkv44qS64gFhxlraMgkRmGwF1fP7oZlNk4mEMJCT9pBsRZx+7BFDCZV IiIiotbiDBYRERERAxYRERERAxYRERHRkvIDO779xeTKXgYAAAAASUVORK5CYII=" name="logo" align="bottom" width="240" height="62" border="0"/>

-

Fast RTPS v@PROJECT_VERSION@

- +

Fast DDS v@PROJECT_VERSION@

Email: support@eprosima.com
Phone: +34 91 804 34 48
www.eprosima.com

@@ -1254,8 +1253,7 @@

  • Installation, User Manual and Release notes

  • -

    eProsima Fast RTPS C++ API html documentation

    - +

    eProsima Fast DDS C++ API html documentation


    Online (updated frequently):


    @@ -1263,13 +1261,13 @@

  • Installation, User Manual and Release notes. (https://fast-dds.docs.eprosima.com)

  • -

    eProsima Fast RTPS C++ API html documentation. (https://fast-dds.docs.eprosima.com/en/latest/fastdds/api_reference/api_reference.html)

    +

    eProsima Fast DDS C++ API html documentation. (https://fast-dds.docs.eprosima.com/en/latest/fastdds/api_reference/api_reference.html)

  • -

    Product Page: Video Tutorials, Whitepapers, benchmarkings (http://www.eprosima.com/index.php/products-all/eprosima-fast-rtps)

    +

    Product Page: Video Tutorials, Whitepapers, benchmarkings (http://www.eprosima.com/index.php/products-all/eprosima-fast-dds)



    Copyright© 2019 eProsima. All rights reserved.

    -

    This copy of eProsima Fast RTPS is licensed to you under the terms described in the LICENSE file included in this distribution.

    +

    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/utils/doxygen/pages/mainpage.dox b/utils/doxygen/pages/mainpage.dox index 38619796280..4c5fe77330a 100644 --- a/utils/doxygen/pages/mainpage.dox +++ b/utils/doxygen/pages/mainpage.dox @@ -1,17 +1,17 @@ /*! - * @mainpage eProsima Fast RTPS library. + * @mainpage eProsima Fast DDS library. *
    *

    Purpose

    - * Real-Time Publish-Subscribe (RTPS) is the wire interoperability protocol defined for the Data-Distribution Service (DDS) standard by - *the Object Management Group (OMG) consortium. This protocol standard is also defined by the OMG in the specification document - *“The Real-Time Publish-Subscribe Wire Protocol. DDS Interoperability Wire Protocol Specification (DDS-RTPS)” that can - *be obtained from the OMG web-page. The main objective of this specification is that all RTPSParticipants in a DDS communication + * Real-Time Publish-Subscribe (RTPS) is the wire interoperability protocol defined for the Data-Distribution Service (DDS) standard by + *the Object Management Group (OMG) consortium. This protocol standard is also defined by the OMG in the specification document + *“The Real-Time Publish-Subscribe Wire Protocol. DDS Interoperability Wire Protocol Specification (DDS-RTPS)” that can + *be obtained from the OMG web-page. The main objective of this specification is that all RTPSParticipants in a DDS communication *structure, even if they use different vendor's implementations, can interoperate. *

    *

    Scope

    - * The scope of this implementation is going to be limited by the RTPS protocol specification of the OMG. Since the main purpose - *of this design is to facilitate the implementation of a standalone RTPS wire protocol as close to the specification as possible, - *the included features will be the ones described in the OMG document. The OMG specification defines message formats, interpretation + * The scope of this implementation is going to be limited by the RTPS protocol specification of the OMG. Since the main purpose + *of this design is to facilitate the implementation of a standalone RTPS wire protocol as close to the specification as possible, + *the included features will be the ones described in the OMG document. The OMG specification defines message formats, interpretation *and usage scenarios for any application willing to use RTPS protocol * The most important features are: *
      @@ -23,7 +23,7 @@ *

      System architecture

      * A general view of the system architecture can be found below: * - * The Fast RTPS library provides the user with two different layers to access its capabilities. The first is the RTPS layer, contained in the + * The Fast DDS library provides the user with two different layers to access its capabilities. The first is the RTPS layer, contained in the * RTPSDomain. Using this layer, the user can directly create RTPSWriter and RTPSReader type objects and access their * corresponding Histories. To facilitate the use of this layer an additional Publication-Subscription layer has * been developed. This second layer allows the user to create Publishers and Subscribers associated to certain topics and @@ -34,22 +34,22 @@ The correct behavior of the RTPS protocol will be achieved by using an event-bas

      Thread Structure

      For each RTPSParticipant, various threads will be spawned to manage different aspects of the RTPS implementation. Each application using this implementation will at least have the following threads: -
      • Main thread: This will be the thread managed by the application or the user. The user will interact with the objects through the defined public APIs. +
        • Main thread: This will be the thread managed by the application or the user. The user will interact with the objects through the defined public APIs.
        • Receive thread: These threads will be in charge of listening to the different ports. Since these threads will be blocked until a RTPS message is received there will be a different thread for each different IP-port combination that the RTPSParticipant is listening from. Multiple endpoints can be assigned to the same listening thread.
        • Event thread(s): This thread will be in charge of processing events triggered by some periodic condition, or by actions performed by the user in the main thread. In this version a single event thread will be created and used per RTPSParticipant.

        Resource Structure

        There are three main types of resources in the implementation, that directly correspond with three classes. All resources are managed by the RTPSParticipant. -
        • ResourceListen: Each listen resource is assigned to a single IP:port combination. It receives and processes messages directed to that socket and performs the necessary actions in one or more of the associated Writers or Readers. In this version each ResourceListen runs a single thread listening to a single socket. Future versions may allow the association of multiple sockets (multiple ResourceListen objects) with a single listen thread. -
        • ResourceEvent: This resource manages the time-delayed event triggered periodically or by some message-based event. A single resource is implemented per RTPSParticipant, with a single thread performing all the actions. Future versions may include multiple ResourceEvents running in multiple threads to improve performance. +
          • ResourceListen: Each listen resource is assigned to a single IP:port combination. It receives and processes messages directed to that socket and performs the necessary actions in one or more of the associated Writers or Readers. In this version each ResourceListen runs a single thread listening to a single socket. Future versions may allow the association of multiple sockets (multiple ResourceListen objects) with a single listen thread. +
          • ResourceEvent: This resource manages the time-delayed event triggered periodically or by some message-based event. A single resource is implemented per RTPSParticipant, with a single thread performing all the actions. Future versions may include multiple ResourceEvents running in multiple threads to improve performance.
          • Event thread(s): This resource manages ALL send operations in the RTPSParticipant. This means that all endpoints included in an RTPSParticipant send their messages through the socket defined in this resource. All messages are send synchronously. Future versions will include multiple ResourceSend objects and the possibility to asynchronously send messages.

          Main events

          There are multiple events that are triggered wither directly by some action performed by the user, the reception of messages or even periodically. A list of the main events and the actions that need to be performed after them is included below, whereas a detailed description of all the events associated with each class of the design will be included in the detailed implementation chapter. -
          • User-triggered events: These events are triggered directly after the user performs some action, either directly to the RTPS Writer or its associated HistoryCache. +
            • User-triggered events: These events are triggered directly after the user performs some action, either directly to the RTPS Writer or its associated HistoryCache.
            • Message-triggered events: These events are triggered by the reception of an RTPS message. For example, the reception of an ACKNACK message would trigger a change in the status of some CacheChanges in the HistoryCache and, maybe, the re-send of some packets to a specific Reader.
            • Periodic events: Some events must be triggered periodically according to DDS rules. For example, heartbeat packets must be send each heartbeatPeriod to all matching Readers.