Re: [opendds-main] Rti interoperability

[Adam M. <mi...@oc...>]

Hi Chris,

On 4/28/2015 9:21 AM, Adam Mitz wrote:
> I don't have any more ideas since my last email, still really looks 
> like alignment is off.  I'm going to try a test of shifting the data 
> around with just OpenDDS and wireshark.

Here's an annotated hex dump from wireshark. I'm attempting to send this 
next part as fixed-width so it lines up, not sure if it will work well.

0000   00 01 00 00 63 00 00 00 10 00 00 00 18 00 00 00
        CDR_LE opts l1          l2          l3

0010   00 00 00 00 00 00 60 40 08 00 00 00 10 00 00 00
        d1          *           l4          l5

0020   18 00 00 00
        l6

This shows the alignment working as expected, no padding is added in 
this case.  The value of l1 is 99=0x63 in my test since I left it 
unchanged from the Messenger test, the others should match what you had.

To explain what you observed with RTI DDS, if d1 shifted down to start 
at the byte marked *, OpenDDS would see d1 as 0 (padding bytes + top 
bytes).  Then l4 becomes 0x40600000=1,080,033,280 as you saw.

It also explains the other test not working, since that would have the 
opposite problem (RTI DDS doesn't add padding but OpenDDS requires it).

The relevant parts of the RTPS spec are in section 9.4.2.12:
"Note that when using CDR, primitive types must be aligned to their 
length. For example, a long must start on a 4-byte boundary. The 
boundaries are counted from the start of the CDR stream."
and section 10.1.1.1:
"All data encapsulation schemes must start with an encapsulation scheme 
identifier.
The identifier occupies the first two octets of the serialized data-stream"

This is how we know that the encapsulation header is counted as part of 
the stream and not coming before it.

I think our next step would be to develop a compatibility configuration 
option in OpenDDS.

Thanks,
Adam Mitz
Principal Software Engineer
Object Computing, Inc.