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
| Attachment | Size |
|---|---|
 DDS Network.PNG | 9.65 KB |
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
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:
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
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
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
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
rtiddspingdata being received and printed (echoed) byrtiddsspy? NOTE: I should have suggested you runrtiddsspy -printSampleso you could see the data values printed as it is received...Assumming that you do indeed get the data printed when you run
rtiddspingon PC-W and runrtiddsspy -printSampleon 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/rtiddsspyis 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 likeNDDSHOME,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-qosProfileoption)rtiddsping. Run the application with a current working directory that does not contain the fileUSER_QOS_PROFILES.xml-- I say this so thay you are using the default QoS and not automatially picking up something in theUSER_QOS_PROFILES.xmlrtiddsspy -printDataon PC-M. Do you see the data being received/printed there? NOTE: I would expect so based on the fact thatrtiddsping&rtiddsspydo comminicate.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.xmlGerardo