Is data de/marshalling a DDS standard? PreviousNext
Data Distribution Service (DDS) Forum > DDS FAQ >
Message/Author
Next message Anonymous posted on Wednesday, February 04, 2009 - 03:49 pm
I've been looking into a couple different DDS vendors and noticed that RTI points out that it handles data marshalling. OpenSplice doesn't mention it anywhere on their site. I also didn't see any mention of it in the DDS spec v1.2.

Since DDS is supposed to allow for communication across networks, you can bet that some nodes might be running a different OS. So de/marshalling should be important. Is it something that is just assumed?
Next message Angelo Corsaro  posted on Wednesday, February 04, 2009 - 05:54 pm
Hello,

The DDS v1.2 specification does not specify data marshaling because it does not specify a wire protocol, it only specifies and API. What it expects however, is that implementation of the API take care of the issues related to byte-ordering and efficient network representation of data.

The marshaling format is specified in the DDSIv2.1 specificaion as being the CDR (Common Data Representation). This makes sense since the DDSI (former RTPS) defines an interoperability wire-protocol.

That said, OpenSplice DDS takes care of data marshaling. As prescribed by the standard it uses CDR for its DDSI implementation, while a CDR variation is used in its real-time networking technology.

Hope this answers your question.

Cheers,
Angelo
Next message John Hawkins  posted on Wednesday, February 04, 2009 - 07:08 pm
hi Angelo,

Am I right in saying (I've asked this in a different thread before now) that a provider must "at least" be able to handle CDR i.e. they could use their own format if they wish - but there is no standard way of saying what the format is if you are not the same provider. Or has this been hardened in the DDSI spec (not read it yet - sorry).


thanks,
John
Next message Angelo Corsaro  posted on Thursday, February 05, 2009 - 10:02 pm
Hello John,

If you look at the DDSIv2.1 specification (available here http://www.omg.org/docs/ptc/08-06-13.pdf) you'll see that sections 9 and 10 address precisely data encapsulation. Moreover, as described in section 9.2.2, compliant implementation should encapsulate data and messages using CDR.

That said, DDSIv2.1 has a field that allows to specify the kind of encapsulation used for data, this will be leveraged by the upcoming specification on "Extensible and Dynamic Topic Types" which will add support for other kind of encapsulation other than CDR.

BTW, if you want to read a summary on the "Extensible and Dynamic Topic Types" check out the dds4u.blogspot.com blog.

Hope this answers your question.

Cheers,
Angelo
Next message Stephan Poehlsn  posted on Wednesday, April 15, 2009 - 08:12 am
Hello,

I have a few questions concerning the following statement


quote:

it [OpenSplice] uses CDR for its DDSI implementation, while a CDR variation is used in its real-time networking technology.




1. OpenSplice still has different serialization methods? I thought all current DDS vendors are trying to use DDSI 2.1 for interoperability reasons.

2. Is the performance of OpenSplice better with the proprietary CDR variation?

3. Is it possible to force OpenSplice to use the DDSI serialization?

Thanks,
Stephan
Next message matt c  posted on Wednesday, June 03, 2009 - 07:26 am
I'm very interested in this topic as well. Namely, will vendor A's DDS implementation be inter-operable with vendor B's?

I'm having trouble with this para from the DDS Wire Protcol spec page 5 - "The DDS specification does not address the protocol used by the implementation to exchange messages over transports
such as TCP/UDP/IP, so different implementations of DDS will not interoperate with each other unless vendor-specific
“bridges” are provided. The situation is therefore similar to that of other messaging API standards such as JMS."

and would like some guidance on this.
Next message Hans van 't Hag  posted on Wednesday, June 03, 2009 - 12:51 pm
Stephan, Matt,

As Angelo explained, the OMG-DDS specification doesn't prescribe the wire-format and thus basically addresses portability rather than interoperability when dealing with multiple vendors/DDS-implementations.

To explicitly address interoperability between multiple DDS-vendors, an additional specification has been drafted called DDSI.

As an interoperability protocol targeted to be implemented by multiple vendors that might have different internal architectures, its limited 'by nature' in providing a best-fit for all situations. Therefore, in our product (OpenSplice DDS) we provide the choice between our native protocol (that maximally exploit our internal architecture that was driven by scalability and mission-criticality requirements for large-scale control/combat systems)and/or the DDSI protocol. Since both are available runtime 'pluggable services' one can even combine both in a single system.
Next message matt c  posted on Wednesday, June 03, 2009 - 11:28 pm
Thankyou, my error was reading DDS as DDSI.
Back to top
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message
Action: