Example Code - Achieving 'Batching' by setting push-on-write to false
Note: Applies to RTI Connext 4.0 and above.
This example shows how to achieve batching without using the Batch QoS policy (which was introduced in 4.4).
Publisher
This Publisher sends out bursts of 32 keyed reliable samples at 20Hz. The point here is that the dataWriterQos.protocol.push_on_write = DDS_BOOLEAN_FALSE. This means that the samples are not written on the write call. They are pulled by the Reader when the Reader acknowledges the Writer's reliable heartbeat (HB) with a NACK message. The Writer's HB tells the Reader that it has the 32 sample burst. The Reader responds with a NACK, which says that it does not have it. The Writer responds with repair messages that contain the missing 32 samples.
The test case sets the UDPv4.builtin.parent.gather_send_buffer_count_max parameter. The default is 16; which aggregates about 5-6 samples. Its maximum value is 128, which would aggregate about 48 samples.
If you look at the wire traces of this test case, you will see that DefaultGatherSendBufferCount.pcap shows 5-6 data samples per user data packet and that GatherSendBufferCount128.pcap shows about 48 data samples per user-data packet.
Some reasons for this use case other than "batching":
- It is compliant with the DDS specification—no DDS extensions are used.
- Aggregation can exceed the transport size without requiring asynchronous publication.
Subscriber
The Subscriber polls the Reader with take() at a 10Hz rate.
Building
Make sure you are using one of the relevant RTI Connext versions as specified at the top of the solution. Before compiling or running the example, make sure the environment variable NDDSHOME is set to the directory where your version of RTI Connext is installed.
Run rtiddsgen with the -example option and the target architecture of your choice (for example, i86Win32VS2005). The RTI Connext Core Libraries and Utilities Getting Started Guide describes this process in detail. Follow the same procedure to generate the code and build the examples. Do not use the -replace option.
After running rtiddsgen like this...
C:\local\Pre-4.4Batch\c++> rtiddsgen -language C++ -example i86Win32VS2005 sequences.idl
...you will see messages that look like this:
File C:\local\Pre-4.4Batch\c++\tbf_subscriber.cxx already exists and will not be replaced with updated content. If you would like to get a new file with the new content, either remove this file or supply -replace option. File C:\local\Pre-4.4Batch\c++\tbf_publisher.cxx already exists and will not be replaced with updated content. If you would like to get a new file with the new content, either remove this file or supply -replace option.
These messages are normal and are only informing you that the subscriber/publisher code has not been replaced, which is fine since all the source files for the example are already provided.
Running
In two separate command-prompt windows for the publisher and subscriber, navigate to the objs/<architecture> directory and run these commands with the domain_ID and gather_send_buffer_count_max of your choice (the arguments are explained below):
Windows systems
sequences_publisher.exe <domain ID> 100 <gather_send_buffer_count_max> sequences_subscriber.exe <domain ID> 100
UNIX-based systems
./sequences_publisher <domain ID> 100 <gather_send_buffer_count_max> ./sequences_subscriber <domain ID> 100
The first two arguments are the same for each application:
<domain ID>. Both applications must use the same domain ID in order to communicate. The default is 0.- How long the examples should run, measured in samples for the publisher and sleep periods for the subscriber. A value of '0' instructs the application to run forever; this is the default.
The sequence_publisher application accepts a third argument for gather_send_buffer_count_max.
While generating the output below, we used values that would capture the most interesting behavior.
Publisher Output
On Publication matched-> Now start writer Waiting on pub match return code error -> 0 Got publisher match - so start blasting data
Subscriber Output
Samples per second = 0 On Subscription Matched on liveliness changed Samples per second = 416 Samples per second = 512 Samples per second = 512 Samples per second = 352 Samples per second = 416 Samples per second = 544 on liveliness changed On Subscription Matched Samples per second = 480 Samples per second = 0 Samples per second = 0
