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?
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.
posted on Wednesday, February 04, 2009 - 07:08 pm
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).
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.
I have a few questions concerning the following statement
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?
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."
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.
posted on Wednesday, June 03, 2009 - 11:28 pm