|
From: Adam M. <mi...@oc...> - 2015-04-28 15:00:47
|
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.
|