Navigating IIoT Protocols: Comparing DDS and MQTT
The convergence of Operational Technology (OT) and Informational Technology (IT) has become a strategic imperative for organizations aiming to unlock...
RTI is the world’s largest DDS supplier and Connext is the most trusted software framework for critical systems.
|
From downloads to Hello World, we've got you covered. Find all of the tutorials, documentation, peer conversations and inspiration you need to get started using Connext today.
RTI provides a broad range of technical and high-level resources designed to assist in understanding industry applications, the RTI Connext product line and its underlying data-centric technology.
RTI is the largest software framework company for autonomous systems. The company’s RTI Connext product enables intelligent architecture by sharing information in real time, making large applications work together as one.
As you probably know, DDS data is sent on the wire as RTPS messages. As such, these messages include a header and the data payload. The header contains useful information such as host ID, remote ID and sequence numbers; we’ll refer to the payload as ‘data sample’. For instance, in this Wireshark capture you can see the header and two submessages: INFO_TS, which contains the timestamp info, and DATA_FRAG, which is actually a data sample fragment.
Knowing that, it may come as a surprise to discover that RTPS messages are not the ones actually sent on the wire. RTI Connext ® DDS relies on a transport that sends the messages from the host to the remote application over the network. That transport, by default, is UDPv4. So each RTPS message needs to be wrapped as UDP datagrams that the OS (or the IP Stack in general) can send. At the same time, UDP runs on top of an IP stack, which also splits and wraps messages with its own headers.
In short, RTPS messages need to be wrapped inside UDP datagrams first, which are, at the same time, encapsulated into IP fragments. To complicate everything a bit more, UDPv4 datagrams have a maximum size of 64KB while IP packets for a Ethernet LAN has usually a Maximum Transmission Unit (MTU) of 1500 Bytes. This means that an 80KB data sample would need to be split up into 2 UDP datagrams: one of 44 IP fragments and another one of 11 (see image below).
As you can see, your DDS data sample is going to be split several times, and then reassembled before getting to your application.
On one hand, for IP fragments, the IP stack will mark each of the fragments as part of a bigger message and indicate the position (offset) of that fragment in that message. Once all of the fragments arrive at the socket/kernel reception buffer, the IP stack will transfer the reassembled UDP packet to the DDS application.
On the other hand, DDS is prepared to reassemble the split data sample fragments -called DATA_FRAG in the DDS standard and in the Wireshark capture above- into your original data sample before notifying the application that new data is available.
There are mainly three scenarios in which fragmentation could affect your communication using DDS:
If any of these scenarios happen, you may not see any communication at all between your DDS applications. You can review this article on how to confirm if IP fragmentation is the cause of your lack of communication and how to fix it.
Even if your applications communicate, IP fragmentation may still affect your performance.
If an IP fragment is lost, the DDS layer will not receive data from the IP layer. From the point of view of Connext DDS, the RTPS packet containing that fragment is lost, and may require resending it.
When you use best effort delivery, resending will not happen. If you are sending large data with best effort (for streaming, for instance), this will result in a very inefficient usage of your network. For example, if you send a full HD image (1920x1080 pixels), you will be sending around 6 MB of data. If one IP fragment is lost (1500 bytes), you will discard 99.99% of the data that arrived correctly to the receiver.
When you use reliable delivery, DDS will only resend the RTPS fragment for which IP fragment was lost. In our example, the 6 MB image will be split in ~95 DATA_FRAGs of the maximum UDP datagram size (if message_size_max is set to 65KB, the default value). When one IP fragment is lost, 64KB of data will need to be resent, which is only about 1% of the data.
In both cases, if your DDS application is continuously resending data sample fragments due to packet loss, it may end up affecting your overall performance (both throughput and latency). When using Connext DDS, there are several QoS considerations to mitigate this performance loss. To learn more about the specifics of these configurations, be sure to read this Knowledge Base post over on the RTI Community portal.
The convergence of Operational Technology (OT) and Informational Technology (IT) has become a strategic imperative for organizations aiming to unlock...
A Comparison of DDS, TLS and DTLS Security Standards
Meet New RTI Team Member Marcos Rivera! Work environments around the globe have changed as a result of the recent pandemic, and the structure of...