Copies in the Middleware Memory Space

You are here:

23.2 Copies in the Middleware Memory Space

Figure 23.3: Number of Copies Out-of-the-Box shows how many times Connext DDS may copy a large sample sent over UDP or shared memory. The diagram assumes that the samples have to be fragmented by the middleware (via DDS fragmentation) because their serialized size is greater than the underlying transport MTU (maximum transmission unit), which can be configured by setting message_size_max in the transport properties (see 16. Transport Plugins). Note that these are copies in the middleware memory space—the operating system network stack may make additional copies.

Figure 23.3: Number of Copies Out-of-the-Box

For both UDP and shared memory (SHMEM), the copies are as follows, out of the box:

Copy 1 is the serialization copy. Connext DDS calls TypePlugin::serialize to convert the in-memory representation of a sample, such as a C++ object, into a data representation, called a wire representation, with a format suitable for storage or transmission.

After a sample is serialized, it is sent to the subscribing application using one or more of the available transports. When the underlying transport maximum message size is smaller than the serialized size of the sample, the sample must be fragmented. The fragmentation process does not require any extra copy. Fragments refer directly to offsets in the serialization buffer.

Note: The transport maximum message size can be configured using the property dds.transport.UDPv4.builtin.parent.message_size_max for UDPv4 and dds.transport.shmem.builtin.parent.message_size_max for SHMEM. There are equivalent properties for other transports, such as TCPv4 and UDPv6.

Copy 2: For SHMEM, the sample fragments that live in the local memory space of the publishing process have to be copied into the shared memory segment from which the subscribing application will read them. For UDP, the call to the socket receive operation copies the fragments.
Copy 3: After they are received, the sample fragments are reassembled into a single buffer.
Copy 4 is the deserialization copy. Connext DDS calls TypePlugin::deserialize to convert the wire memory representation of a sample into its in-memory representation, such as a C++ object.

Figure 23.4: Number of Copies Using FlatData Language Binding

FlatData is a language binding in which the in-memory representation of a sample matches the wire representation. Therefore, the cost of serialization/deserialization is zero. You can directly access the serialized data without deserializing it first. When using FlatData language binding, Copy 1 and Copy 4 in Figure 23.3: Number of Copies Out-of-the-Box are removed for both UDP and SHMEM communications. See Figure 23.4: Number of Copies Using FlatData Language Binding.