How to send big TypeCodes and TypeObjects

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

In this solution we show how to configure RTI Connext to send TypeCodes and TypeObjects larger than the default maximum serialized sizes (2kB and 3kB respectively). In this example, the modifications needed to the transport settings are shown for the UDPv4 builtin transport.

Note that the TypeObject representation of the data is only supported by RTI Connext 5.0.0 and above

It's not necessary to send both TypeCodes and TypeObjects. They are both representations of the type and it's field. For example, if all applications are using at least RTI Connext 5.0.0 it is only necessary to send the TypeObject. However, if there is at least one application that is using RTI Connext 4.5f or earlier, then TypeCode should be used. You can send only one by setting the other max_serialized_length to 0.

This solution consists of three possible scenarios:

- Sending TypeCode/TypeObject <= 9kB.

- Sending TypeCode/TypeObject <= 64kB.

- Sending TypeObject > 64kB.

Scenario 1) Sending TypeCode/TypeObject <= 9kB

By default, RTI Connext is configured to send TypeCodes with a maximum serialized size of 2kB and TypeObjects with a maximum serialized size of 3kB. You can change this default behavior by modifying the DomainParticipantResourceLimitsQos:

<participant_qos>
    <resource_limits>
        <type_code_max_serialized_length>4096</type_code_max_serialized_length>
        <type_object_max_serialized_length>4096</type_object_max_serialized_length> 
    </resource_limits>
</participant_qos> 

Note that this is only valid if the resulting datagram (after including not only the TypeCode and/or TypeObject, but the rest of RTPS information) has a serialized size smaller than 9kB (which is the default maximum message size). In the next section we show how to increase this limit.

Scenario 2) Sending TypeCode/TypeObject <= 64kB

If the resulting RTPS message has a size between 9kB (the default maximum message size) and 64kB (the maximum UDP packet size), we must have to modify the UDPv4 settings to support larger message sizes. The following XML snippet shows the needed configuration:

<participant_qos>
    <receiver_pool>
        <buffer_size>65530</buffer_size>
    </receiver_pool>

    <property>
        <value>
            <element>
                <name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name>
                <value>1048576</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.builtin.parent.message_size_max</name>
                <value>65530</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.builtin.send_socket_buffer_size</name>
                <value>65530</value>
            </element>
        </value>
    </property>
      
    <resource_limits>
        <type_code_max_serialized_length>65530</type_code_max_serialized_length>
        <type_object_max_serialized_length>65530</type_object_max_serialized_length> 
    </resource_limits>
</participant_qos> 

 If our topic's TypeCode or TypeObject size is equal or close to 64kB (the maximum UDP packet size), we may obtain the following error:

"COMMENDSrWriterService_on_Submessage:!write resend. Reliable large data requires asynchronous write"

In this case, please refer to the following section.

Scenario 3) Sending TypeObject >64kB.

Although using a TypeCode greater than 64kB is not supported, we can use the TypeObject.

In general, the TypeObject representation is smaller than the equivalent TypeCode. However, a TypeObject of 64kB could not be enough for certain deployments. In these cases, we need to enable the Asyncronous Reliable Built-in DataWriter. This can be done using the following configuration:

<participant_qos>
    <receiver_pool>
        <buffer_size>65530</buffer_size>
    </receiver_pool>

    <discovery_config>
        <publication_writer_publish_mode>
            <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
        </publication_writer_publish_mode>
        <subscription_writer_publish_mode>
            <kind>ASYNCHRONOUS_PUBLISH_MODE_QOS</kind>
        </subscription_writer_publish_mode>
    </discovery_config> 
 
    <property>
        <value>
            <element>
                <name>dds.transport.UDPv4.builtin.recv_socket_buffer_size</name>
                <value>1048576</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.builtin.parent.message_size_max</name>
                <value>65530</value>
            </element>
            <element>
                <name>dds.transport.UDPv4.builtin.send_socket_buffer_size</name>
                <value>65530</value>
            </element>
        </value>
    </property>
      
    <resource_limits>
        <type_object_max_serialized_length>131072</type_object_max_serialized_length> 
    </resource_limits>
</participant_qos> 

It is important to note that using asynchronous writing have other impacts, like longer time for writes (depending on flow controller settings), additional thread creation and complexity. Therefore, this mode should only be used when necessary.

You can refer to this solution which explains how to use RTI Monitor to view the TypeCode size of your types.
 
Platform:

Comments

Hello, In my RTI DDS application I am not using any examples file which are in RTI DDS workspace instead I am using other programs which are inbuilted with java programming when I run one of the log file I get error as default msg size is 1250 which is less than the local msg size which is 65507 how to solve this error and how to change the maximum msg length