Publishing through multiple networks

6 posts / 0 new
Log in or register to post comments
Last post
Fri, 11/22/2013 - 08:15
#1
tiger_galo
Offline
Last seen: 10 years 12 months ago
Joined: 09/17/2013
Posts: 10
Publishing through multiple networks

 

Hi Folks,

I am having hard time with publishing through multiple networks. The image above kind of diplays the picture of the networks and PCs in the networks. Next to each PC I stated whether it is a publisher and/or subscriber. The brief intrudaction of my issue is the following.

The PC W publishes some data over the Real Time Network (RTN hereafter). The PC R as a subscriber receives those packages over the RTN. The PC W has two network cards and in the QoS file I have in the allow interfaces list both addresses: PC R and PC M. So I suppose that PC M should also receive the published data, but it does not. Whereas the PC R is publishing other data over the User Network (UN hereafter) and PC M receives that data over the UN. I just cannot understand why the data published by the PC W, which supposed to be published into both networks (RTN and UN) is available to the PC R but not to the PC M.

I have also tried multicast option, tried allow interfaces lists, tried having no filtering in the QoS for the addresses, b ut nothing helped. I believe there is a way to activate publication through multiple networks.

One more thing to be mentioned, even if I have in my allow interfaces list only the addresses from the UN network anyway I don't receive anything on that network. It seems like PC W doesn't publish through the UN network, only through the RTN.

And another short question would be if we need to assign different domain IDs for different neetworks, or perhaps we can use the same domain ID for all participants for all networks?

Any ideas, any help, please.

 

Thanks a lot,
Tiger

AttachmentSize
Image icon DDS Network.PNG9.65 KB
Top
Fri, 11/22/2013 - 16:51
Juanjo Martin
Juanjo Martin's picture
Offline
Last seen: 2 years 3 months ago
Joined: 07/23/2012
Posts: 48

Hi Tiger,

By default, you should not need to modify the initial peers or the allow_interfaces_list. Multicast is configured by default to be used by discovery and it should get your applications communicating each other.

If that doesn't happen, maybe it is because the network doesn't allow multicast. In that case, you should need to set in the initial peers (DiscoveryQos) the IP addresses of all the PCs you want to communicate each other.

There is no need to use the allow_interfaces_list. It is commonly used to allow an interface that was previously denied using deny_interfaces_list (for instance, we deny 10.10.* and we allow 10.10.1.1). 

Also, you can instrument the callbacks related to discovery and match (liveliness and publication/subscription match) to find out if they are discovering each other.

About your domain question, there is no need to set a different domain for a different network. Domains are used to split logically applications that are physically connected, but if you don't want to split anything... you can use same domain for all your applications.

I hope this helps, keep posting more information/questions if needed.

Juanjo Martin

Top
Sun, 11/24/2013 - 16:19
Gerardo Pardo
Gerardo Pardo's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 06/02/2010
Posts: 602

Hi,

I agree with Juanjo. This should work out of the box without special configuration...

I would suspect something in the network configuration of PC-W is amiss given that PC-R can communicate with PC-M but PC-W cannot. What operating system are you running on these PCs?

The most likely culprit is some firewall setting. If you haev any firewalls on PC-W or PC-R disable them.

I would try the following steps to see if they shed some light:

  1. ping from PC-W to PC-M and and also from PC-M to PC-W  (I assume you already tried, but I list it for completeness)
  2. run rtiddsping on PC-M and rtiddsspy on PC-W
  3. run rtiddsping on PC-W and rtiddsspy on PC-M

If 1 works, but 2 and 3 do not work. I would repeat steps 2 and 3 now running Wireshark capturing the packets on the PC-W interface attached to the User Network and look if you see any RTPS traffic there. If you capture this and can post it to this forum thread and we can take a look.

Gerardo

Top
Mon, 11/25/2013 - 06:53
tiger_galo
Offline
Last seen: 10 years 12 months ago
Joined: 09/17/2013
Posts: 10

Hi guys,

Thank you for all your suggestions. I will try and will post the new results.

The operating system is Win7 on all those PCs.

Thanks,
Tiger

 

Top
Mon, 11/25/2013 - 07:54
tiger_galo
Offline
Last seen: 10 years 12 months ago
Joined: 09/17/2013
Posts: 10

Hi Juanjo,
Hi Gerardo,

I tried all 3 steps as per Gerardo's advise and all of them were successful. I tried Discovery QoS with initial peers setting all addresses, but still on PC M I cannot receive the data published by PC W through UN.

Any other suggestions? Anything else to try?

Thanks,
Tiger

Top
Mon, 11/25/2013 - 10:31
Gerardo Pardo
Gerardo Pardo's picture
Offline
Last seen: 3 weeks 2 days ago
Joined: 06/02/2010
Posts: 602

Hello Tiger,

First a question. When you said  "I tried all 3 steps as per Gerardo's advise and all of them were successful",  do you mean that in steps 2 and 3 you could see the rtiddsping data being received and printed (echoed) by rtiddsspy?   NOTE: I should have suggested you run rtiddsspy -printSample so you could see the data values printed as it is received...

Assumming that you do indeed get the data printed when you run rtiddsping on PC-W and run  rtiddsspy -printSample on PC-M then it would indicate there is no issue with your network setup (firewalls, etc) or the RTI DDS installation, therefore the problem has to be with the configuration of your application, discovery, QoS settings, etc. 

This is what I would try, assuming the above:

First make sure you understand the configuration rtiddsping / rtiddsspy is using when you see it working from PC-W to PC-M. Are you running them from the command-line? Are you setting any special DDS-related environment variables, things like NDDSHOME, NDDS_DISCOVERY_PEERS, on those consoles that you do not set when you run your application? Are you specifying a special qos profile when you run rtiddsping / rtiddsspy (i.e. using the -qosProfile option) 

  1. Run your publishing application on PC-W, without specifying any environment variables different than when you run rtiddsping. Run the application with a current working directory that does not contain the file USER_QOS_PROFILES.xml -- I say this so thay you are using the default QoS and not automatially picking up something in the  USER_QOS_PROFILES.xml 
  2. Run rtiddsspy -printData on PC-M. Do you see the data being received/printed there? NOTE: I would expect so based on the fact that rtiddsping & rtiddsspy do comminicate.
  3. Assuming that on 2 above you are indeed getting data on rtiddsspy, then repeat 1 and now run your subscribing application o PC-M, also without specifying any environment variables different than when you run rtiddsspy and also with a current working directory that does not contain the file USER_QOS_PROFILES.xml
  4. Assuming that in 3 you do not get data, then it must be that something is not consistently set. Topic name, Domain Id, Type name or schema, Compatible QoS.  The fastest way to trouble-shoot this is to run the RTI Analyzer tool. Do you have access to this tool? If you do not have access you can see a lof of information by running rtiddspy and your applications as rtiddspy will print some of the discovery information. You can also try downloading the RTI Connext DDS View experimental tool from this link.

Gerardo

Top