|Receiver pool thread(s). |
|The receive buffer size. |
|The receive buffer alignment. |
This QoS policy is an extension to the DDS standard.
RTI uses a separate receive thread per port per transport plug-in. To force RTI Connext to use a separate thread to process the data for a DDSDataReader, set a unique port for the DDS_TransportUnicastQosPolicy or DDS_TransportMulticastQosPolicy for the DDSDataReader.
This QoS policy also sets the size of the buffer used to store packets received from a transport. This buffer size will limit the largest single packet of data that a DDSDomainParticipant will accept from a transport. Users will often set this size to the largest packet that any of the transports used by their application will deliver. For many applications, the value 65,536 (64 K) is a good choice; this value is the largest packet that can be sent/received via UDP.
Receiver pool thread(s).
There is at least one receive thread, possibly more.
[default] priority above normal.
The actual value depends on your architecture:
For Windows: 2
For Solaris: OS default priority
For Linux: OS default priority
For LynxOS: 29
For INTEGRITY: 100
For VxWorks: 71
For all others: OS default priority.
[default] The actual value depends on your architecture:
For Windows: OS default stack size
For Solaris: OS default stack size
For Linux: OS default stack size
For LynxOS: 4*16*1024
For INTEGRITY: 4*20*1024
For VxWorks: 4*16*1024
For all others: OS default stack size.
The receive buffer size.
The receive buffer is used by the receive thread to store the raw data that arrives over the transport.
In many applications, users will change the configuration of the built-in transport NDDS_Transport_Property_t::message_size_max to increase the size of the largest data packet that can be sent or received through the transport. Typically, users will change the UDPv4 transport plugin's NDDS_Transport_Property_t::message_size_max to 65536 (64 K), which is the largest packet that can be sent/received via UDP.
buffer_size should be set to be the same value as the maximum NDDS_Transport_Property_t::message_size_max across all of the transports being used.
If you are using the default configuration of the built-in transports, you should not need to change this buffer size.
In addition, if your application only uses transports that support zero-copy, then you do not need to modify the value of buffer_size, even if the NDDS_Transport_Property_t::message_size_max of the transport is changed. Transports that support zero-copy do not copy their data into the buffer provided by the receive thread. Instead, they provide the receive thread data in a buffer allocated by the transport itself. The only built-in transport that supports zero-copy is the UDPv4 transport on VxWorks platforms.
[range] [1, 1 GB]
The receive buffer alignment.
Most users will not need to change this alignment.
[range] [1,1024] Value must be a power of 2.