Fast RTPS  Version 1.4.0
Fast RTPS
 All Classes Namespaces Functions Variables Typedefs Enumerations Enumerator Friends Groups Pages
eProsima Fast RTPS 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 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 and usage scenarios for any application willing to use RTPS protocol The most important features are:

  • Enable best-effort and reliable publish-subscribe communications for real-time applications.
  • Plug and play connectivity so that any new applications are automatically discovered by the other members of the network.
  • Modularity and scalability to allow continuous growth with both complex and simple devices in the network.

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 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 transmit user-defined TopicDataTypes between them.

Behavior Implementation

The correct behavior of the RTPS protocol will be achieved by using an event-based implementation. Multiple events will be handled by different threads allowing the application to efficiently tackle the different tasks. The thread structure, as well as the main events will be discussed in this section.

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.
  • 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.
  • 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.
  • 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.