Who Is Chopping My Application Data and Why Should I Care?

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.

Read More

Service Provision and Discovery

This is an abstract of a demo that RTI plans to have available at the RTI Connext Users Group meeting, to be held in London next month.

Read More

Simplifying the use of DDS

The specification for DDS provides great capability for applications that want to leverage the distribution of state data in a very customized efficient manner. I say customized here because not only can you specify the unique type of data but you can also specify the behavior of how that data will be delivered, persisted, filtered and stored within the middleware. Actually, the capabilities provided by DDS are not unique to data communications between systems. However, what DDS provides is all of this functionality within the middleware, thus eliminating the need for your applications to provide the same. No coding necessary...

Read More

One Admin Console To Debug Them All!

Better RTI Connext® DDS debugging is now available with Admin Console!

Read More

Built-in QoS Profiles

One of the great things about DDS is the variety of Quality-of-Service (QoS) settings that are available to a user. These QoS settings help to fine-tune any DDS application to fit a use case's every specification. With all of this choice, however, comes great responsibility… and possibly a few headaches along the way. QoS configuration has historically been an obstacle for DDS users and I'm happy to announce that with our latest release of RTI Connext DDS 5.1.0 we have introduced built-In QoS profiles that will help to alleviate those initial aches and pains.

Read More

DDS and Delegated ... Durability?

Implementation requirements seem to come in waves, where several different customers will come forward with the same specific requirement. Sometimes this is driven by a government RFI, so they are working from the same blueprint. Sometimes the companies might be in different industries looking at different required results, and stumble upon the same solution set requirements. One example of the different source, same result request was "How do we enable load balancing using RTI Connext DDS?"

Several recent customers had a specific need that wasn't directly addressed by our configuration options or documentation. Thinking about the implementation requirements afterwards, I came up with a neologism that describes what they were looking for.

Read More