Are there issues sending between DDS 5.3.0 .NET and C++ applications with 4.2E and 4.3 Large Message Support?

1 post / 0 new
Log in or register to post comments
Wed, 03/28/2018 - 11:01
#1
sjevans
Offline
Last seen: 5 years 5 months ago
Joined: 06/24/2016
Posts: 7
Are there issues sending between DDS 5.3.0 .NET and C++ applications with 4.2E and 4.3 Large Message Support?

Hello,

We are using DDS 5.3.0 and DDS 4.2e with large messages.

In this instance we need to be able to send and receive data between applications built with DDS 4.2e / VS2003 on x86, and applications built with DDS 5.3.0 / VS2015 on x64.

I have taken the HelloWorld example, and used it to explore any issues which could occur first.

What I have found is that the C++, modern C++, and DDS 4.2e test applications are quite happy to exchange data between them with no problems seen. The C++/CLI and C# test applications are happy to exchange data between them with no problems seen. However there seems to be an issue exchanging data between the C++ / Modern C++ / DDS 4.2e test applications and the C++/CLI and C# test applications.

The IDL file contents are:

const long HELLODDS_MAX_PAYLOAD_SIZE = 131072;
const long HELLODDS_MAX_STRING_SIZE = 64;

@appendable
enum Reference
{
    ONE,
    TWO
};

struct HelloWorld
{
    string<HELLODDS_MAX_STRING_SIZE>             prefix;
    long                                         sampleId;
    sequence<octet, HELLODDS_MAX_PAYLOAD_SIZE>   payload;

    double                                       value;

    Reference                                    the_datum;
   
    unsigned long                                checksum;
};

When sent by the C++/CLI or C# application to the other test applications:

  • The payload is the right size and the contents appear to be correctly transferred;
  • The double value does not seem to be decoded properly in the C++ and Modern C++ applications – it looks like the value has not been deserialized properly, or the buffers are not aligned properly – it seems to effectively be a random small number approximately equal to e-314;
  • The enumeration value is always zero / the first value;
  • The checksum is always zero;
  • The 4.2e application does not decode the sample at all, but generates the following message:

PRESPsReaderQueue_storeQueueEntry:!deserialize
PRESPsReaderQueue_newData:!store entry

Going the other way (from the standard C++ application, or the modern C++ application, or the DDS 4.2e application) to the .NET applications:

  • The payload is the right size and the contents appear to be correctly transferred;
  • The double value is always zero;
  • The enumeration value is always zero / the first value;
  • The checksum seems to be actually decoded from the enumeration value.

The command used to generate the example C++/CLI project was:

rtiddsgen.bat HelloWorld_Test.idl -ppDisable -language C++/CLI -update typefiles -update examplefiles -update makefiles -platform x64Win64VS2015 -use42eAlignment

The other languages used the same command, other than changing the -language value.

I have defined the following in the USER_QOS_PROFILES.XML file:

  • dds.data_writer.type_support.use_42e_alignment in the datawriter_qos, datareader_qos, and participant_qos.
  • dds.data_reader.type_support.use_42e_alignment (because I was not sure if there was a typo in the documentation) in the datareader_qos and participant_qos.
  • dds.sample_assignability.accept_unknown_enum_value in the datareader_qos and participant_qos.
  • dds.data_writer.protocol.use_43_large_data_format in the participant_qos.
  • dds.data_reader.protocol.use_43_large_data_format in the participant_qos.

I think that there is a misalignment problem after deserialising the payload, which causes everything deserialised afterwards to be incorrect.

Any suggestions?

Top