Fast-RTPS is not DDSI-RTPS 2.2 Compliant [9146]

[Greek64]

Fast-RTPS doen not follow the DDS Interoperability Wire Protocol Specification Version 2.2 as specified by OMG (DDSI-RTPS 2.2).

Problem

Fast-RTPS uses random source UDP ports as default source for its RTPS massages, but does not provide an InfoReply Submessage with the correct UDP source ports. A Receiver thus has to keep state from all relevant sources and determine the reply UDP ports from the GUID. This goes against the RTPS Protocol Specification, and prevents a Stateless Writer (as defined in the reference example of the Standard) from being able to communicate with an Fast-RTPS Entity.

Violations

The Fast-RTPS implementation more specifically violates following clauses:

Subclause 8.4.2.1.2 of Clause 8.4.2 Behavior Required for Interoperability which states:

All implementations must implement the RTPS Message Receiver
Implementations must implement the rules followed by the RTPS Message Receiver, as introduced in 8.3.4, to interpret
Submessages within the RTPS Message and maintain the state of the Message Receiver.

This requirement also includes proper Message formatting by preceding Entity Submessages with Interpreter
Submessages when required for proper interpretation of the former, as defined in 8.3.7.

Subclause 8.4.8.2.6 of Clause 8.4.8 RTPS StatelessWriter Behavior further explains:

Note that the processing of this message uses the reply locators in the RTPS Receiver. This is the only source of
information for the StatelessWriter to determine where to send the reply to. Proper functioning of the protocol requires
that the RTPS Reader inserts an InfoReply Submessage ahead of the AckNack such that these fields are properly set.

Solution

Include an InfoReply Submessage with the correct RTPS Locator in every outgoing RTPS Message that expects a response, or use the correct UDP ports to begin with.

[JLBuenoLopez]

Hi @Greek64,

Sorry for the late reply. While being true that Fast DDS does not implement a InfoReply submessage, Fast DDS only implements reliability using the Stateful Writer. Fast DDS implementation does not allow a Stateless Writer to be reliable and therefore there is no need to send the InfoReply submessage. Thanks for your concern!

[Greek64]

Well, although I understand your reasoning, I would argue that this does not change the fact, that Fast-DDS is NOT DDSI-RTPS 2.2 compliant, as it claims to be. The spec is pretty clear on what compliance entails. 8.4.2 Behavior Required for Interoperability states:

This sub clause describes the requirements that all implementations of the RTPS protocol must satisfy in order to be:
• compliant with the protocol specification,
• interoperable with other implementations.

And, as already stated in OP, it violates clause 8.4.2.1.2, because it does not include proper Message formatting by preceding Entity Submessages with Interpreter Submessages when required for proper interpretation of the former, as defined in 8.3.7.

The whole point of RTPS is interoperability. A Stateless Writer cannot interoperate with your implementation, ergo your implementation is NOT compliant.

---

I understand my tone is a bit strict here, but compliance is a BIG statement, and most often than not quite difficult to achieve and test. I also understand that this may never be fixed, due to fundamental obstacles, but then the statements on compliance should be removed. As per the COMPLIANCE statement in the spec:

Software developed under the terms of this license may claim compliance or conformance with this specification if and
only if the software compliance is of a nature fully matching the applicable compliance points as stated in the
specification. Software developed only partially matching the applicable compliance points may claim only that the
software was based on this specification, but may not claim compliance or conformance with this specification.

[JLBuenoLopez]

Hi @Greek64,

Thanks for your concern and for your thorough investigation. I think you are right. I am going to reopen the issue and we will allocate some time to add this message to Fast DDS.

[MiguelCompany]

@Greek64 I have just drafted PR #2678 with a possible fix.

Do you know of a DDS implementation using a stateless reliable writer against which we could check interoperability?

[Greek64]

Do you know of a DDS implementation using a stateless reliable writer against which we could check interoperability?

Unfortunately not. Originally I started writing a stateless implementation (that is how I came across this issue), but along the way ended up with a stateful implementation.

Than again I would argue that this is the responsibility of the DDS Foundation to test it in their interoperability test suite. But I have not looked through the test suite (don't know what and how it tests interoperability), and it looks unmaintained.

[JLBuenoLopez]

It has been decided that this is not going to be fixed. Fast DDS interoperability has been tested against several DDS vendors and it does not seem that any current vendor is implementing the reliability protocol using a StatelessWriter instead of a Stateful one. Consequently, until there is a vendor implementing that part of the specification, this is not going to be fixed.