|
RTI Connext Modern C++ API
Version 6.1.1
|
Support for the queuing communication pattern. More...
Modules | |
| QueueProducer | |
| QueueProducer and associated elements. | |
| QueueConsumer | |
| QueueConsumer and associated elements. | |
| QueueRequester | |
| QueueRequester and associated elements. | |
| QueueReplier | |
| QueueReplier and associated elements. | |
Support for the queuing communication pattern.
The queuing communication patterns provides a load-balancing communication model in which a sample sent by a QueueProducer is received exactly by one QueueConsumer.
This pattern requires running RTI Queuing Service.
If there are no QueueConsumers available when the sample is sent, the sample will be stored in a SharedReaderQueue hosted by RTI Queuing Service until a QueueConsumer is available to process the sample.
If a QueueConsumer receives a sample and does not acknowledge it before a specified amount of time or it acknowledges it negatively, the sample will be redelivered to a different QueueConsumer.
A SharedReaderQueue is the result of the association of a Topic with a SharedSubscriber, where a SharedSubscriber is a container that hosts SharedReaderQueues within RTI Queuing Service.
The queuing API implements four basic entities:
#include <rti/queuing/rtiqueuing.hpp> or by including each header file individually. A QueueProducer sends samples to a Queuing Service instance, which stores them in a SharedReaderQueue.
A QueueConsumer receives samples from a SharedReaderQueue hosted by a Queuing Service instance.
QueueProducers and QueueConsumers do not communicate directly; they need the mediation of Queuing Service.
QueueProducers and QueueConsumers communicate with Queuing Service using different Topics.
A QueueProducer has an underlying DataWriter that publishes samples on Topic 'aTopicName'. This is the SharedReaderQueue Topic.
A QueueConsumer has an underlying DataReader that receives samples on Topic 'aTopicName@aSharedSubscriberName'.
QueueProducer and QueueConsumer are simple components that provide basic queuing communication in one direction: from QueueProducer to QueueConsumer.
The RTI Connext DDS Queuing API also supports the request-reply use case, in which samples sent by a QueueRequester are expected to generate a reply from the QueueReplier that consumed the request.
The QueueReplier produces a reply for each request that it consumes. Queuing Service correlates and delivers that reply to the QueueRequester that produced the request.
QueueRequester and QueueReplier are the components that provide the request-reply functionality. QueueRequesters and QueueRepliers do not communicate directly. They always require the mediation of Queuing Service:
QueueRequesters and QueueRepliers communicate with Queuing Service through regular SharedReaderQueues. The communication from a QueueRequester to a QueueReplier is identical to the basic queuing use-case for Producers and Consumers. The communication from a QueueReplier to a QueueRequester is also similar, with the key difference that replies from the reply SharedReaderQueue are only delivered to the QueueRequester that originally sent the associated request.
The queuing request-reply pattern can also be implemented by using the simple QueueProducer and QueueConsumer components. In this case, your application must create the necessary QueueProducers and QueueConsumers to communicate with the request and reply SharedReaderQueues, as well as perform the correlation of the request and reply samples.
All the available entities and associated infrastructure are built on top of RTI Connext. You can find detailed information about this pattern and the DDS mapping in the RTI Queuing Service User's Manual.
The Queuing communication pattern is only available with RTI Connext Messaging.