RTI Connext C API
Version 5.3.0
|
Allows sending requests and receiving replies. More...
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 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 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 ID.
A Requester can send requests and receive one or multiple replies. It does that using the following operations:
In all cases, the middleware guarantees that a requester only receives reply samples that are associated with that 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 reliable quality of service. The exact default configuration is described here: Configuring Request-Reply QoS profiles