Allows sending requests and receiving replies. More...

Detailed Description

Allows sending requests and receiving replies.

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

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

To create a Requester for two types, a request type TReq=Foo and a reply type TRep=Bar, your application needs to instantiate the data structure FooBarRequester and the specific operations that can publish and subscribe to those types. In this documentation we refer to the type-dependent operations as FooBarRequester_ (for example, FooBarRequester_take_replies). Some operations are type-independent and their name always begins with RTI_Connext_Requester_ (for example, RTI_Connext_Requester_wait_for_replies).

See Creating a Requester to see how to instantiate a FooBarRequester.

A Replier and a Requester communicate when they use the same topics for requests and replies (see RTI_Connext_RequesterParams::service_name) on the same domain.

A Requester can send requests and receive one or multiple replies. It does that using the following operations:

Sending requests (i.e. publishing request samples on the request topic)
Waiting for replies to be received by the middleware (for any request or for a specific request)
Getting those replies from the middleware. There are two ways to do this: take (the data samples are removed from the middleware), read (the data samples remain in the middleware and can be read or taken again).
A convenience operation, receive (which is a combination of wait and take).

In all cases, the middleware guarantees that a requester only receives reply samples that are associated with those requests that it sends.

For multi-reply scenarios, in which a Requester receives multiple replies from a Replier for a given request, the Requester can check if a reply is the last reply of a sequence of replies. To do so, see if the bit DDS_INTERMEDIATE_REPLY_SEQUENCE_SAMPLE is set in DDS_SampleInfo::flag after receiving each reply. This indicates it is NOT the last reply.

A requester has an associated DDS_DomainParticipant, which can be shared with other requesters or RTI Connext routines. All the other RTI Connext entities required for the request-reply interaction, including a DDS_DataWriter for writing requests and a DDS_DataReader for reading replies, are automatically created when the requester 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 DDS_RELIABLE_RELIABILITY_QOS. The exact default configuration is described here: Configuring Request-Reply QoS profiles

See also: FooBarReplier; Request-Reply Examples; Requester example