Allows receiving requests and sending replies. More...

Detailed Description

Allows receiving requests and sending replies.

A Replier is an entity with two associated topics: a request topic and a reply topic. It can receive requests by subscribing to the request topic and can send replies to those requests by publishing the reply topic.

Valid types for these topics (TReq and TRep) are: those generated by the rtiddsgen code generator, the DDS built-in types, and DynamicData. Note: At this moment, in the C version of this API, only rtiddsgen-generated types are supported.

To create a Replier for two types, a request type TReq=Foo and a reply type TRep=Bar, your application needs to instantiate the data structure FooBarReplier and the specific operations that can publish and subscribe to those types. In this documentation we refer to the type-dependent operations as FooBarReplier_ (for example, FooBarReplier_take_requests). Some operations are type-independent and their names always begin with RTI_Connext_Replier_ (for example, RTI_Connext_Replier_wait_for_requests). See Creating a Replier.

A Replier has four main types of operations:

Waiting for requests to be received from the middleware
Getting those requests
Receiving requests (a convenience operation that is a combination of waiting and getting in a single operation)
Sending a reply for a previously received request (i.e., publishing a reply sample on the reply topic with special meta-data so that the orignal Requester can identify it)

Much like a Requester, a Replier has an associated DDS_DomainParticipant, which can be shared with other Repliers or RTI Connext routines. All the other entities required for the request-reply interaction, including a DDS_DataWriter for writing replies and a DDS_DataReader for reading requests, are automatically created when the Replier is constructed.

Quality of Service for the underlying DataWriter and DataReader can be configured (see RTI_Connext_RequesterParams::qos_profile_name). By default, they are created with reliable quality of service. The exact default configuration is described here: Configuring Request-Reply QoS profiles

There are several ways to use a Replier:

A thread receives requests and then dispatches them. If the computation of a reply is a simple operation, consider using a FooBarSimpleReplier instead of a Replier.
Polling without waiting, using FooBarReplier_take_requests directly.
Using a RTI_Connext_ReplierListener to get notified and get the requests within the callback.

See Also: FooBarRequester; Request-Reply Examples; Basic Replier example