What is the maximum message size supported by RTI Connext 4.x and above?

Note: Applies to RTI Connext 4.x and above.

Prior to RTI Data Distribution Service 4.1d, the maximum message size supported by RTI Data Distribution Service was determined by the installed transports. Each transport may impose a maximum message size. The maximum message size supported by a transport is configured using the transport properties.

Starting with 4.1d, the 'large data' feature is supported. When the middleware needs to send data which is larger than the maximum data size supported by the transport, the middleware will automatically fragment the sample. Upon receiving all fragments, the middleware will automatically reassemble the fragments into one large data sample. Only when all fragments have been received will the data sample be provided to the user application.

For example, when sending a 1Mbyte file over UDP, the sample will be fragmented based on the maximum message set in the UDP transport. By default this is 9K. However, depending on the operating system, the UDP transport settings can be increased to about 64K fragments. To improve throughput, it is important to configure the transport to the maximum supported on your platform.

When sending the same data using multiple transports, the smallest limit among all the transports applies and a large data sample will be fragmented based upon the smallest limit.

RTI Connext 4.x and above installs two transports by default: UDPv4 and shared memory. The default transport properties limit the maximum message size to 9K. To increase this limit, you must modify the transport properties.

Note that it may not be possible to increase the maximum message size property to an arbitrary limit. The UDPv4 protocol, for example, limits the size of a single message to 64K. Hence, the UDPv4 transport cannot support messages larger than 64K. There is no built-in limitation to the maximum message size over shared memory. 

Increasing the maximum message size property

To increase the maximum message size property, follow the instructions in the online (HTML) documentation (select Modules, Programming How-To's, Transport Use Cases).

For example, to increase the maximum message size supported by the built-in UDPv4 transport to 64K, use the following code snippet to modify the transport properties: 

property.parent.message_size_max = 65535; 
property.recv_socket_buffer_size = 65535; 
property.send_socket_buffer_size = 65535; 

In addition to changing the transport properties, you must also configure the maximum buffer size that will be loaned to the transport by the RTI Connext receive threads. This buffer is used by the transport to copy the raw data into, for further processing by RTI Connext (note this does not apply for transports that use zero-copy, as mentioned in the online documentation). The buffer size must be large enough to hold the maximum message size. To change the buffer size, modify the buffer_size in the DomainParticipant's ReceiverPool QoS policy before creating the DomainParticipant. Its default value is 9K. For example:

participant_qos.receiver_pool.buffer_size = 65535;

Attached is an XML file which shows how to specify the properties as part of an XML QoS profile to configure the DomainParticipant and transport properties. (applies to version 4.3 and higher)

<dds>
  <qos_library name="UDPv4TransportLibrary">
    <qos_profile name="DefaultProfile" is_default_qos="true">
      <participant_qos>
        <receiver_pool>
          <buffer_size>65535</buffer_size>
        </receiver_pool>
        <property>
          <value>
            <element>
              <name>dds.transport.UDPv4.builtin.parent.message_size_max</name>
              <value>65535</value>
            </element>
            <element>
              <name>dds.transport.UDPv4.builtin.send_socket_buffer_size </name>
              <value>65535</value>
            </element>
            <element>
              <name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name>
              <value>65535</value>
            </element>
            <element>
              <name>dds.transport.shmem.builtin.parent.message_size_max</name>
              <value>65535</value>
            </element>
            <element>
              <name>dds.transport.shmem.builtin.receive_buffer_size</name>
              <value>65535</value>
            </element> 
          </value>
        </property>
      </participant_qos>
    </qos_profile>
  </qos_library>
</dds> 

If you are using RTI Data Distribution Service 4.3e, you must call  DDSTheParticipantFactory->load_profiles() before creating the DomainParticipant with a profile.

When using RTI Connext 4.4 and above, the XML file can be automatically loaded. If NDDS_QOS_PROFILES.xml is in the $NDDSHOME/resource/xml directory, it will be automatically loaded. Similarly, if USER_QOS_PROFILES.xml is in the working directory, it will be automatically loaded. See theCore Libraries and Utilities User’s Manual for more details on XML file loading.

When using version RTI Connext 4.4 and above, place the attached USER_QOS_PROFILES.xml file in the working directory. It specifies  NoMulticastLibrary as the default QoS profile and will be loaded when your DDS application starts.

Final notes

• If you see the message " NDDS_Transport_UDPv4_receive_rEA:!precondition" in the DDS logging output, it likely means the  receiver_pool.buffer_size is not large enough to hold the maximum message size.

• RTI Connext will add a small amount of overhead to the user data. Therefore, the actual amount of user data that can be sent using RTI Connext in the above example is slightly smaller than 64K.

• Since version 5.0.0, discovery data can be sent using asynchronous writing. For more information about this, please refer to the solution http://community.rti.com/kb/how-send-big-typecodes-and-typeobjects.