Receiving DDS messages in Java

4 posts / 0 new
Last post
Offline
Last seen: 7 years 3 weeks ago
Joined: 03/22/2017
Posts: 2
Receiving DDS messages in Java

I am new to DDS, and have a task to integrate a Java application with a C++ application that runs on a different PC and has already written that uses DDS. We have a license for the C++ application. I have several questions about this:

  1. Is it possible to receive DDS messages in the Java application over a plain socket and parse them?
  2. Do I need an RTI license on the machine running the Java application?
  3. If the C++ application is publishing messages are they automatically serialized, or does that need to be added to the C++ application?
  4. Is there a specific port that I need to listen to with a UDP server?

In the resources I have found it doesn't seem like anyone has done anything specifically like this, so any help you can give me would be much appreciated.

Thanks!

Keywords:
Offline
Last seen: 3 months 6 days ago
Joined: 02/11/2016
Posts: 144

Hey,

1.

RTI uses the RTPS wire protocol which by default is using the UDP transport protocol.

You could, with the right amount of effort, write the necessary code to communicate with an RTI-based application using a plain udp socket.

That is not recommended, though :)

2.

I'll leave the licensing questions to RTI.

3.

If you are using the RTI to publish messages (using writer.write, for example) then yes, RTI will serialize the data.

4.

RTI uses the term "domain" to describe a "world" within which applications can communicate on different topics.

When the c++ application publishes messages it does so on a writer that is identified with some topic, and belongs to some domain (represented by the domain participant which created it).

By default, a domain maps to a range of ports used to communicate on that domain.

Normally (if multicast is available), a participant discovery phase is done over the multicast discovery port (if the multicast discovery port is unavailable, unicast discovery ports are used), followed by an endpoint discovery phase which is done (by default) using unicast and a small range of ports, and ultimately data is sent from a writer to a reader (although the actual sending and receiving is managed by publishers and subscribers) using unicast on the ports used for endpoint discovery.

A short version answer for the above is that RTI uses the concept of domains and a domain normally translates into a range of 250 ports dedicated to that domain (+shared memory addresses dedicated to that domain).

The formula I know of is 7400 + domain_id * 250 being the lower end of the port range (so that domain 0 translates to 7400-7649).

 

Hope this helps?

Roy.

Offline
Last seen: 7 years 3 weeks ago
Joined: 03/22/2017
Posts: 2

Thank you, that helps quite a bit. My understanding is that this path is not worth the effort and I would like to justify buying a license to my customers.

sara's picture
Offline
Last seen: 1 year 4 months ago
Joined: 01/16/2013
Posts: 128

Hi,

Adding something to what Roy mentioned:

1. I agree with Roy, this is feasible but will require a big effort. 
2. In most cases, we do not require licenses running in the deployed systems. Our licensing model is per developer and project, independent of the number of applications/devices your need to run.
3. Connext DDS serializes the data and do the conversion from the Java/C types to DDS types so the transition is automatic for you
4.  You can find which ports are needed in this post: https://community.rti.com/kb/what-network-port-numbers-does-rti-connext-use

I hope this helps. If you have more questions regarding licensing, feel free to send an email to sales-emea (AT) rti.com and one of our account managers will get back to you. Or send it to me and I will forward it: sara (AT) rti.com

Thanks,
Sara