Anonymous posted on Monday, April 06, 2009 - 04:29 pm
I've been looking into OpenDDS and was wondering if it truely was a DDS implementation. After reading about the info repo, it looks like it's a client/server architecture and not a pub/sub one.
The description about the info repo states that it is not used for data popogation, but only for allowing publishers and subscribers of the same topics to discover each other.
I don't see any reason why the publishers and subscribers would be discovering each other in a pub/sub architecture since they are supposed to be completely decoupled. Unless it's a client/server architecture.
Can anyone shed some light on this?
Anonymous posted on Monday, April 06, 2009 - 04:39 pm
Also does anyone know what it means when they say they don't implement a Real Time Publish-Subscribe transport layer? Is that what is typically used to propogate data through the DDS network?
Don't know if this thread is still alive, but just in case anyone stumbles past:
The OMG Real-Time Publish-Subscribe wire protocol, or RTPS, is a separate standard from the core DDS standard. It is the interoperability protocol for communicating between different DDS implementations, and is also referred to as DDSI.
An implementation is not required to use RTPS internally and does not need to include RTPS in order to be DDS-compliant.
RTPS implementations are only just coming onto the market; interoperability between OpenSplice, RTIDDS and (I believe) CoreDX was demonstrated at the OMG Technical Meeting in March 2009.
OpenDDS 1.3 was released in July 2009. It does not implement enough of the QoS policies to meet the Minimal compliance profile. The important ones of these (in my opinion) are Presentation, Ownership and Destination_Order.
So technically OpenDDS is not yet a proper DDS implementation because it does not meet the Minimum compliance profile.
As regards the data propagation vs discovery, well the various DDS entities do need to discover one another in order to send data to one another. This does not make the architecture a client/server one; OpenSplice and RTIDDS have discovery mechanisms too - just not CORBA-based ones.
The DDS standard has very little to say on the subject of discovery, since it is an implementation-internal mechanism. Using CORBA is thus not prohibited, and this in itself does not make OpenDDS less standard-compliant than any other implementation.
OpenDDS is moving closer to full minimum profile compliance, as well as adding support for QoS from additional profiles (including Presentation, Ownership, and Destination_Order). We are also working on bringing the APIs up-to-date with the DDS v1.2 specification.
OpenDDS does not (yet) implement the DDSI specification. Incremental steps in that direction are happening, but there simply has not been enough interest and funding from the user community to make it happen. The DCPSInfoRepo does indeed use CORBA, but only for discovery of topics, participants, subscriptions, publications. It is definitely not involved in pub/sub communications.
Watch http://www.opendds.org for details. The OpenDDS 1.3 release is available there, as well as expanded and improved documentation. We will try to keep readers of this forum informed of future news about OpenDDS.
Hi, We are using openDDS for publish/subscribe middleware. We download, installed, configured and did other necessary steps of openDDS to start development. We were successful in running example programs. We have a clarification : Is it necessary for the entire installation and configuration procedure of openDDS need to be done in PC where the subscriber application is running?.Any minimal requirements /dependencies alone (necessary libraries or dependencies of openDDS)can be identified and installed for a subscriber application to work?