Connext DDS uses internal threads, known as Receive threads, to process the data packets received via underlying network transports. These data packets may contain meta-traffic exchanged by DomainParticipants for discovery, or user data (and meta-data to support reliable connections) destined for local DataReaders.
As a result of processing packets received by a transport, a Receive thread may respond by sending packets on the network. Discovery packets may be sent to other DomainParticipants in response to ones received. ACK/NACK packets are sent in response to heartbeats to support a reliable connection.
When a DDS sample arrives, the Receive thread is responsible for deserializing and storing the data in the receive queue of a DataReader as well as invoking the on_data_available() DataReaderListener callback (see Setting Up DataReaderListeners).
The number of Receive threads that Connext DDS will create for a DomainParticipant depends on how you have configured the QosPolicies of DomainParticipants, DataWriters and DataReaders as well as on the implementation of a particular transport. The behavior of the builtin transports is well specified. However, if a custom transport is installed for a DomainParticipant, you will have to understand how the custom transport works to predict how many Receive threads will be created.
The following discussion applies on a per-transport basis. A single Receive thread will only service a single transport.
Connext DDS will try to create receive resources1If UDPv4 was the only transport that Connext DDS supports, we would call these receive resources ‘sockets.’ for every port of every transport on which it is configured to receive messages. The TRANSPORT_UNICAST QosPolicy (DDS Extension) for DomainParticipant, DataWriters, and DataReaders, the TRANSPORT_MULTICAST QosPolicy (DDS Extension) for DataReaders and the DISCOVERY QosPolicy (DDS Extension) for DomainParticipants all configure the number of ports and the number of transports that Connext DDS will try to use for receiving messages.
Generally, transports will require Connext DDS to create a new receive resource for every unique port number. However, this is both dependent on how the underlying physical transport works and the implementation of the transport plug-in used by Connext DDS. Sometimes Connext DDS only needs to create a single receive resource for any number of ports.
When Connext DDS finds that it is configured to receive data on a port for a transport for which it has not already created a receive resource, it will ask the transport if any of the existing receive resources created for the transport can be shared. If so, then Connext DDS will not have to create a new receive resource. If not, then Connext DDS will.
The TRANSPORT_UNICAST, TRANSPORT_MULTICAST, and DISCOVERY QosPolicies allow you customize ports for receiving user data (on a per-DataReader basis) and meta-traffic (DataWriters and DomainParticipants); ports can be also set differently for unicast and multicast.
How do receive resources relate to Receive threads? Connext DDS will create a Receive thread to service every receive resource that is created. If you use a socket analogy, then for every socket created, Connext DDS will use a separate thread to process the data received on that socket.
So how many threads will Connext DDS create by default–using only the builtin UDPv4 and shared memory transports and without modifying any QosPolicies?
Three Receive threads are created for meta-traffic2Meta-traffic refers to traffic internal to Connext DDS related to dynamic discovery (see Discovery (Chapter 1 on page 1). :
Two Receive threads created for user data:
Therefore, by default, you will have a total of five Receive threads per DomainParticipant. By using only a single transport and disabling multicast, a DomainParticipant can have as few as 2 Receive threads.
Similar to the Database and Event threads, a Receive thread is configured by the RECEIVER_POOL QosPolicy (DDS Extension). However, note that the thread properties in the RECEIVER_POOL QosPolicy apply to all Receive threads created for the DomainParticipant.
© 2018 RTI