47.1 The Request-Reply Pattern

The request-reply pattern has two roles: The requester (service consumer or client) sends a request message and waits for a reply message. The replier (service provider) receives the request message and responds with a reply message.

Using the request-reply pattern with a Replier is straightforward. Connext provides two Entities: the Requester and the Replier manage all the interactions on behalf of the application. The Requester and Replier automatically discover each other based on an application-specified service name. When the application invokes a request, the Requester sends a message (on an automatically-created request Topic) to the Replier, which notifies the receiving application. The application, in turn, uses the Replier to receive the request and send the reply message. The reply message is sent by Connext back to the original Requester (using a different automatically created reply Topic).

Connext supports both blocking and non-blocking request-reply interactions:

• In a blocking (a.k.a. synchronous) interaction, the requesting application blocks while waiting for the reply. This is typical of applications desiring remote-procedure-call or remote-method-invocation interactions.
• In a non-blocking (a.k.a. asynchronous) interaction, the requesting application can proceed with other work and gets notified when a reply is available.

48.2 Repliers explains how an application can use the methods provided by the Requester and the Replier to perform both blocking and non-blocking request-reply interactions.

The implementation of request-reply in Connext is highly scalable. A Replier can receive requests from thousands of Requesters at the same time. Connext will efficiently deliver each reply only to the original Requester, allowing the number of Requesters to grow without significantly impacting each other.

47.1.1 Request-Reply Correlation

An application might have multiple outstanding requests, all originating from the same Requester. This can be as a result of using a non-blocking request-reply interaction, or as a result of having multiple application threads using the same Requester. Because of this, Connext provides a way for the application to correlate a reply with the request it is associated with. This meta-data is provided as part of a SampleInfo structure that accompanies the reply.

When using a blocking request operation, Connext provides an easy-to-use API that automatically does the correlation for you.

47.1.2 Standard Compliance

By default, the Connext Request-Reply and RPC communication patterns are not fully compliant with the OMG DDS RPC specification. With Connext 7.4.0 and higher, you can configure Connext to be compliant. For more information, see Chapter 53 Standard Compliance.