Configure Domain ip for communication across different network

[holyna]

I've played with the RTI DDS publisher/subscriber examples on my computer with no problem. I'd like to try to run publisher and subscriber on different ip network. By going through the RTI instructions and online tutorials, I haven't really come across to anything tells me how to setup the ip address using the toolkit module. Should I configure this in "domainParticipantQoSProfile" or "Domain ID". Is there an simple example demonstrating the configuration?

Thanks,

[TheEngineeringBear]

Hey Holyna,

I actually had this same question, although I haven't set it up before.  When I was researching this, on page 3-3 of the Getting Started Guide it states:

"Note: Under the DDS publish/subscribe paradigm, knowing the location of the distributed applications is handled by the middleware. In this example, we are running both the RTI Connext DDS Write String Example.vi and the RTI Connext DDS Read String Example.vi on the same computer, using the Shared Memory transport for inter-application communication. However, if you were to run these examples on different computers (with a functional LAN connection), DDS would automatically handle the communication across the network."

This makes me believe that 1) you need an active connection between the two different network (i.e. a bridge of some kind) and 2) you will need some middle person software allowing the instrument to be visible.  I believe this is more of a 'networking' question, but what I believe you will need to do is to setup the middleware to make the instrument visible on the other network and then setup the participant on that network.

I'll keep digging along with you.  My current reading's are here!

-Bear

[holyna]

That's a great start, Bear! I know the whole RTI business is based on the "smart routing" and we don't have to do much work finding the nodes. But as a non-expert on middleware, I don't know what information we need. Your quote "However, if you were to run these examples on different computers (with a functional LAN connection), DDS would automatically handle the communication across the network." It should find the other node "automatically". Too bad I don't have a 2nd Labview computer handy, I'm trying to setup another one and see how it works...

Thanks, also keep it updated with your findings please.

[TheEngineeringBear]

So, in my use, I know that when you are on the same network, that line/statement is true.  It is when you are on two networks that the statement doesn't apply.  Just wanted to clarify that!

Also, I believe this is the exact information you need!

-Bear

[holyna]

You just clarified my thoughts. Now, have to move on to the solutions of middleware... Thanks.

[angelmartinez · Accepted solution]

Hello holyna,

DDS sends discovery information to the Initial Peers an application has. By default, these Initial Peers will be pointing to the multicast address. This means that if two applications are on the same network they will discover each other by default. However, if these applications are on different networks we need to configure the Initial Peers manually. We can do it by adding the IP of the machine in a different network to the list of Initial Peers.

These Initial Peers can be configured in different ways:

• NDDS_DISCOVERY_PEERS environment variable
• QoS Profile
• Code (non-LabVIEW applications)

Have a look at the following solution which shows how to set the Initial Peers using the three methods mentioned above: Configure RTI Connext DDS to not Use Multicast.

My recommendation is to set the NDDS_DISCOVERY_PEERS environment variable to point to the IP address in the other network. Although if you are using a specific QoS profile that you have created, you may want to add the initial peers information in the QoS profile. In the "Chapter 5 - Loading Quality of Service Profiles" you can find information about how to load custom QoS profiles.

Note: if you are setting the NDDS_DISCOVERY_PEERS environment variable, you have to make sure that the instance of LabVIEW has loaded the environment variable. Eg: if you set the environment variable from a command prompt you have to run LabVIEW from that command prompt.

You only need to set the Initial Peers in one machine to have communication, but bear in mind the following (A machine with default Initial Peers, B machine with more Initial Peers):

• If we run A and then B
  • B will send the discovery information to A.
  • A exists and responds to B and the communication will happen.
• If we run B and then A
  • B will send the discovery information to A
  • A doesn't exist and won't reply to B.
  • We run A (Initial Peers to multicast, so B won't receive discovery information)
  • B doesn't receive anything
  • After a timeout (I think by default it is 30 secs) B will send again discovery information to their Initial Peers.
  • B will reach A
  • A responds to B and the communication will happen.

So you may want to run the application with the Initial Peers the last one. If you set the Initial Peers in both machines, you don't need to care about it.

If you want to know how discovery works, click here.

Let me know if you have any problems to configure the Initial Peers.

I hope this helps,

Angel.

[holyna]

Angel,

Thanks for the thorough explanation. I've read all the references you provided and I think I understand how it works in principle. The steps involve disable multicasting using the XML file provided in the link (or similar), and use NDDS_DISCOVERY_PEERS to refer to the new QoS xml file, which has the Initial Peers defined within.

As an engineer, not really a programmer. I think what I prefer to see in the future development of the LabVIEW toolkit is to incorporate this function into a LabVIEW module if possible. If you or experts in the field can provide some LabVIEW examples demonstrating the function, that will be even more fantastic!

Thanks,

[angelmartinez · Accepted solution]

Hi holyna,

You can set the NDDS_DISCOVERY_PEERS environment variable to point directly to you initial peers (without changing anything in the XML QoS profile).

About disabling multicast, we can have both, multicast and unicast to a single machine. Eg.

set NDDS_DISCOVERY_PEERS=239.255.0.1;10.10.1.1

This will use multicast and also unicast to the machine in the IP 10.10.1.1, and you can add more initial peers if you need (separated by semicolons ';').

About the QoS, that is a different way of doing the same thing. 

We will look into the possibility of adding a subVI to configure it 🙂

Regards,

Angel.

[holyna]

Brilliant! Thank you, Angel.

Looking forward to the new development on this item.

Cheers,

[holyna]

Hi Angel,

This is an old post and I created the question. Much appreciate your thorough explanation back then. However, I wasn't able to get it working.

With the Covid situation, I can sit down and play with some of the new ideas. I recently spent some time trying to understand the whole DDS structure and I think I've had a better understanding how it works. However, I'm still not able to make the peers talking to each other across the network based on your method. I'm pretty sure I did something wrong and hope you can help me clear the problem.

First, I tried to setup the "NDDS_DISCOVERY_PEERS environment variable to point directly to you initial peers". I used two methods, one is vi method, https://forums.ni.com/t5/LabVIEW/How-to-use-environmental-variable-in-LAbVIEW/td-p/1756970. I set the value as "239.255.0.1;10.10.1.1;MyiP;PartneriP". I used the example Read/Write DDS string vis, where I write something from my iP and hope my partner can read the string from his iP, but it didn't work.

Then I setup the NDDS_DISCOVERY_PEERS environment variable from Windows, https://support.shotgunsoftware.com/hc/en-us/articles/114094235653-Setting-global-environment-variab... and it didn't work neither.

Any suggestion where went wrong?

Thanks a lot.

Dahai