Hi,
Further to watching the following webinar "Interoperability and the Internet of Things – To standardize or not to standardize?",
I read more about Prismtech's Vortex product.
Have you done any comparison with RTI's products?
Thanks,
Raz
The Global Leader in DDS. Your Systems working as one.
I would not bother with OpenSplice DDS, at least not the OpenSource variant.
It does not suport extented types and the software quality is very low.
For example if one OpenSplice publisher publishes an incompatible IDL all OpenSplice applications in the network just exit with an assert.
If a C# publisher sends you a sequence a C++ publisher just crashes.
If you send a lot of messages, the OpenSplice recursive memory cleanup just breaks down and crashes.
RTI supports Shared Memory in its free version, so its at least 2.5-4 times faster with small messages, while OpenSplice fails to perform with bigger messages beeing 20-40 times slower than RTI with 1024 byte messages.
This question is probably better asked on a neutral forum, but in the interest of genuine knowledge sharing, I would like to briefly comment on this. To give full disclosure, I work for PrismTech and have been a developer for their products for 4 years.
With respect to software quality, the code has been thoroughly inspected and deemed good enough to support Europe's air traffic management infrastructure. Since our commercial (OpenSplice) offering is a superset of the community edition, the comment about quality seems unfounded.
We don't have extensible types (XTypes), however we do support extensible typemodels through Google Protocol Buffers, which is a technology that offers similar functionality and has much wider adoption in the industry. The XTypes specification has many outstanding issues, and until these are addressed it will be difficult for any DDS vendor to create a compliant, interoperable XTypes implementation.
The comment about C# sequences is not just true. In fact, sequences in OpenSplice can be truly unbounded whereas in Connext they cannot be.
I don't understand what "recursive memory cleanup" and "lots of messages" have to do with each other. We definitely support systems that send lots of messages, but I have never encountered this issue. Furthermore, since IDL doesn't allow for references, there isn't much recursivivity in cleaning up messages.
With respect to latency, I would like to see the performance benchmarks you are referencing, since I have not seen this in any of my customer evaluations. Also note that shared memory in OpenSplice and Connext are quite different. This would be the wrong place to go into detail, but I would urge you to take a closer look.
There are genuine benefits to both Connext and OpenSplice which are worth exploring. In the interest of a good discussion let's reduce the FUD to a minimum.
Hi Sander,
Maybe English isn't your first language. I would hope that's the reason for "deemed good enough" to support the European ATC. That's what might be called 'damning with faint praise'; it implies that the reason that OpenSplice was chosen was political or regional, not for technical reasons.
I would also be careful about highlighting a lack of support -- indeed, going out of the way to highlight support for something which is not part of the standard -- as it implies that PrismTech isn't really worried about the future of interoperability or is actively trying to fracture the DDS community. With the AMQP, MQTT, OPC-UA, JMS, RESTful, ZeroMQ, RabbitMQ etc etc ad infinitum ad nauseum communities all proclaiming themselves as "THE protocol for the IoT!", any sort of perceived weakness will be exploited (probably by the ZeroMQ people. Bunch a Bloody zealots, they should rename it ZealotMQ).
As for XTypes itself, until and unless the other DDS vendors even /attempt/ to provide an implementation, the Community (the DDS Community, not the community.rti.com) depends on RTIs implementation/investigation/research into what works, what's missing, etc. That's not enough competition for me. Maybe it's just a marketing miss, but I've been unable to find any indication that PrismTech is even working on an implementation of either XTypes, or Secure DDS.
Competition is a great thing. Without PT<->RTI competition however, neither development team has any incentive to push the envelope. I saw this when Wind River and ISI merged, way-back-when, and the ISI code base was retired and VxWorks stagnated. And OpenDDS isn't much of a competitor, since they only add features when it's funded.
Unbounded sequences were achievable as far back as Connext 5.1, using some hacked rtiddsgen templates that targeted the newer rtiddsgen application. They were added as an official part of the 5.2 release (cf here).
If anyone else is still bothering to read this, to briefly expand on Sander's comments about the implemenations of Shared Memory transport, (and still without going into implementation details) ... The point is that the base reasoning on the implementations differ, which is why the implementations differ. From what I understand, OpenSplice targets raw speed over determinism, and RTI targets determinism over raw speed. This difference in targets affects all of memory usage, resource requirements, speed, throughput, etc. But: It is the system architect to decide whether Speed, Determinism, or "Who cares?" is the important bullet point for a shared memory transport -- a system architect who is interested in DDS, needs to have competing implementations to evaluatein the context of their target distributed system and its component applications.
And that goes directly to "Without that, you may as well roll your own middleware until the "Protocol for the IoT" field sorts itself out".
rip
Hi Sander,
With regards to DDS-XTYPES there are some issues that need clarification or improvement, this is true. It is also true that we also had issues with the original interoperability (DDS-RTTPS) and any specification when it is first created. However this did not stop people in the past from getting interoperable solutions while simultaneously resolving the issues via the regular OMG FTF/RTF process. This is the normal process for specifications as more and more people start implementing them.
As far as DDS-XTYPES in particular I am happy to report that it was not so difficult after all! In fact we have already tested many (625!) DDS-XTYPES type-interoperability test-cases between RTI Connext DDS and TwinOaks CoreDX. I am pleased to say the test passed all of the test cases!
As soon as TwinOaks CoreDX releases their new version of the product there will be multiple vendors that support XTYPES and interoperate as expected. We would like to share and try out these test cases with PrismTech as soon as you have something to test with.
If I may I would suggest to the PrismTech team that it would be better to focus the energy on implementing DDS-XTYPES instead of on blaming "specification issues" for the lack of progress on your own implementation.
Gerardo
Hi Sanders,
Regarding the comments robuser made I am also surprised to read them. I know OpenSplice has been deployed insome critical systems already, so it is hard to believe that such severe issues were go un-noticed for long and remain unfixed. Perhaps you could invite robuser to post more details or a specific example/testcase in your own forum so your experts can help overcome his negative impression.
You mentioned Europe's Air Traffic Management (ATM) Infrastructure. As you know this system is still evolving towards deployment and roughly half of it plans to use RTI Connext DDS while the other half plans to use PrismTech. I mention that because the technical leaders in THALES and INDRA were very influential in pushing for and helping the DDS-XTYPES spec. We even met with them to collect their requirements. Therefore I know that at that point in time they really wanted to leverage this capability. It would be great if we were able to get both products to interoperate with XTYPES before the ATM design is frozen and they are no longer able to take advantage of it...
Gerardo
Hi rip, Gerardo,
Indeed, robustness claims about shared memory / community are best validated with existing customers. It doesn't help the DDS community to make unfounded claims about either product being substandard, when the usecases where both products are being deployed clearly speaks to the contrary. Robuser is of course more than welcome to post any concerns about robustness or code quality in the PrismTech forum.
Gerardo, I do share your concerns about XTypes. As you are well aware, both of our teams are working together (at this very moment!) to resolve outstanding issues. Since RTI has been the main contributer to the specification, for which we give credit, it is no surprise that RTI has been able to provide a first implementation. It also means that the specification contains sections which, as you know, heavily conflict with how PrismTech views DDS. With a specification that is as complex as XTypes, it should come as no surprise that fixing those issues takes time.
Even so, I'm sure that when both companies keep an open mind towards improving the XTypes spec, we can speed up its adoption : )
Sander
Glad to hear we are agreeing on this! As you probably know the next revision of DDS-XTYPES (version 1.2) is coming out in December this year. We are looking forward to testing the interoperability with your implementation the same way we are already testing with TwinOaks'...
Gerardo
I just wrote down my experiences of evaluating OpenSplice Community Version for 6 Month. In the OpenSplice forum and also directly to our OpenSplice contact I sent this bugreports but never got an answer. Here in the RTI forum I get more feedback from OpenSplice people than in the OpenSplice forum.
Perhaps it is just the OpenSplice Community Version that sucks, but that would be a very bad marketing move IMHO.
@robuser
That is feedback I take seriously. If you have been making PrismTech aware of issues you were having with our community edition and we have not gotten back to you, that reflects badly on the product for sure. If you could provide me with links to the bugreports / forum posts, that would be greatly appreciated (if you'd like you can PM me). We strive to be as responsive as we reasonably can be with our community, and if you have a different experience, that will need to be brought to our team's attention.
It sounds like you had a frustrating experience with community product, for which I apologize. It is not the feedback we typically get. I look forward to seeing the bugreport, and any other constructive feedback you may have- even though you understandably are now using RTI.
Best, Sander
You can read up in your forums my reports, I have the same name there.
Not a bug, but still bad code quality. Why would you not add a prefix to your defines? So there a just conflics with other libraries like MySQL all over the place.
/opt/OpenSpliceDDS6.4/HDE/x86_64.linux-dev/include/sys/c_metabase.h:378:29: error: expected unqualified-id before '(' token
#define c_type(o) ((c_type)(o))
Another thing documented here:
http://forums.opensplice.org/index.php?/topic/2553-random-crashes/
If I go to a customer with a notebook and I have some application open that publishes some topic with a different idl definition than the applications on the customer infrastructure -> BOOM! All applications on the customers network crash. Even in our development team everyone had to use different domain ids so we would not crash each others applications all the time while working on different versions! RTI just prints a message (not even throws an exception which is good because this could open the door to DDOS attacks) that it could not deserialize a recieved sample.
@rip : you sound like a real winner mate, making fun of people's language skills. "Maybe English isn't your first language. I would hope that's the reason for "deemed good enough" to support the European ATC. That's what might be called 'damning with faint praise'; it implies that the reason that OpenSplice was chosen was political or regional, not for technical reasons. " At that, you are also a pretty poor reader. Clearly, proficiency with English is not a prerequisite for comprehension. How does a selection from a multinational ATC program invite interpretation that OpenSplice was chosen for political reasons? It sounds awfully like sour grapes mate. Now regarding touting GPB as a good innovation... Well... it just is. Unless your head is burried in the sand (or more likely somewhere else), GPB is one of the most popular data description mechanisms in the world. Why wouldn't the DDS community want to leverage a great innovation already available out there? So mate... go pander your crypto-zealotry elsewhere.
Out of curiousity, can I deploy for free what I develop with the RTI community edition? Just curious... Because free is free, right? No strings attached?
We all have days when we misunderstand the context and react orthogonally to the stated intent.
Unless RTI has changed the policy, you can develop and ship products against the community edition, there are no runtime royalties (there are no runtime royalties against the licensed versions either). The difference being who you can ask questions to, if you need support.
RTI may correct me, but that is my understanding.
rip
Section 3a of the license terms seems to explicitly suggest otherwise:
"Except as provided herein, You may not market, distribute or transfer copies of the Software to others. You may not rent, lease, loan or otherwise provide the Software to any third parties."
I can't provide a link to the terms as for some reason that triggers the spam filter, but I'm sure you'll be able to find them.
Hi,
@JayB. This seems a bit off-topic here, I think it would have been better to open a separate thread if you want to ask an unrelated question like this...
Nevertheless, with regards to deploying the RTI Open Community Source, the short answer is yes. You can deploy for free within the infrastructure community. You can read all the details here: http://www.rti.com/downloads/rti-dds.html
Gerardo
If I may,
Jay, Sander: I believe you are asking two different questions, Jay is asking about object code, and Sander is asking about source (rather, pointing to the source code clause). The Source code is freely transferable within an Infrastructure Community (per Gerardo's response). My response was targeting Jay's question, ie the applications that you write, that leverage the Community edition compiled objects.
Rip is right. To close this subject and avoid confusion I will re-state the key aspects of the RTI licensing.
@Sander. Your section 3a excerpt (https://www.rti.com/downloads/license-agreement.html) does not apply to the Open Community Source. The Open Community Source is governed by a this license (https://www.rti.com/downloads/IC-license.html) which does allow redistribution an clearly states (section 2.2) that "All use under this License is without charge".
As I mentioned before a licensing discussion is welcome but does not belong in this thread given the title and leading post. If there are further questions or comments on licensing please post them on a separate forum thread or contact RTI directly.
Thank you all for the lively discussion!
Gerardo
Gerardo! This is great! I really appreciate the explanation. Some friends and I that worked for an SI are thinking about starting a robotics company. We're all pretty versed in DDS. We could just download your community edition, develop with it and then OEM it? Just please confirm for me. This is fantastic mate!
Hi Jay B,
Yes. You can get started immediately by downloading the software from here: https://www.rti.com/downloads/index.html select "Internally funded, pre-proposal IR&D" then contact RTI as described in https://www.rti.com/downloads/rti-dds.html (see right hand side of page under "Infrastructure Community") and request the Open Community Source license. This will define your IIC and get you the IIC Open Community Source license.
Gerardo