Windows 7 Enterprise, RTI Connext 5.0.0
Total noob here...Working with the RTI Connext examples and everything works great running on the same machine. However, when I run Hello_simple's Publisher app on one machine and the Subscriber app on another machine on the same network, I don't see anything received at the subscriber.
Any advice on what network settings to check, etc. would be greatly appreciated.
Hiya,
run rtiddsping -publisher on one side, and rtiddsping -subscriber on the other. If they don't see each other, then it isn't an RTI problem. Probable culprit would be the Windows Firewall. Disable that and rerun the test...
Thanks. Tried that and, sure enough, they don't see each other. Windows Firewall is disabled on both machines though.
Still making my way through the documentation, and I ran across the discussion of the NDDS_DISCOVERY_PEERS file. Is that file necessary for rtiddsping to function over the network? How about for Hello_simple?
Thanks.
Next thing to check: Are they on the same subnet?
Automatic simple discovery over UDPv4 works for Domain Participants that are on the same subnet.
1) Are they on the same subnet,
2) Is UDPv4 available to them,
3) Is UDPv4 multicast enabled, and
4) Are they on the same domain (if you don't supply a -domainId to rtiddsping, then they are using domain 0, so, yes).
If the above are all 'yes', then the simple discovery protocol should be finding them, assuming you havn't changed any of the QoS settings.
If they are still not finding each other, then ... are you sure the firewall is disabled? :) Run Wireshark on one machine, start rtiddsping on the other, and look for the discovery announcements (if Domain ID 0, then look for announcements to port 7400 on the 239.255.0.1 multicast address).
A little more info...
1 - yes
2 - yes
3 - yes
4 - yes
According to IT, Windows Firewall is disabled.
Ran Wireshark on one machine and rtiddsping -publisher on another. Wireshark is detecting the packets from the publisher (dest=239.255.0.1, proto=RTPS, len=566, dst port=7400).
I have IT looking into other network settings. Any other ideas?
Thanks again!
A little more info...
Start rtiddsping -subscriber on one machine -> Start rtiddsping -publisher on another -> When publisher starts up I see the following four lines of text on the subscriber:
"Found 1 additional ping publishers(s)."
"Current publisher tally is: 1"
"Found 1 additional alive ping publishers(s)."
"Current alive publisher tally is: 1"
So, the subscriber is at least recognizing there is a publisher somewhere out there.
If I reverse the startup order (start publishing first, then start subscribing), I see the following two lines of test on the publisher when the subscriber starts:
"Found 1 additional ping subscriber(s)."
"Current subscriber tally is: 1"
Thanks!
Ok, step one is complete (DDS is working as it should, your network isn't in the way).
Start the Admin Console (part of the Professional installer). What does it see?
(If you don't have the Professional package, start rtiddsspy on the distant machine. This would have either the publisher or the subscriber on one machine, and rtiddsspy on the other. Make sure they are all on the same domain.)
I might not have been clear on the previous post. The ping subscriber never reports receiving any data, just that it found the publisher.
Running rtiddsping -publisher on one machine and rtiddsspy (I am not using the Professional package) on another...spy reports receiving the packets. Specifically, the first line of output from spy reports Info = "W +N", topic = "PingTopic", type = "PingType". The rest of the lines output report the same except with Info = "d +N".
Running rtiddsping -publisher on one machine and rtiddsspy (I am not using the Professional package) on another...spy reports receiving the packets. Specifically, the first line of output from spy reports Info = "W +N", topic = "PingTopic", type = "PingType". The rest of the lines output report the same except with Info = "d +N".
There's something wrong with your QoS then. The "d +N" says that keyed instances (new ones) are being successfully received. You might try adding -printSample to the arguments for rtiddsspy.
What rtiddsspy did differently is that it auto-configured it's DataReader's QoS in order to be compatible with the Writer. This implies it's a QoS mismatch problem.
If ping is reporting it sees the peer but no data flows, that is usually an indication that discovery is not completing over UDP. It's started with multicast (which stage appears to have worked) but then the unicast fallow-through never completed.
Things like this are why we recommend buying the tools, btw :) Either Analyzer or Admin Console would straight away tell you which QoS isn't correct or if there is incomplete discovery (the Participants are shown but no endpoints). Without them, you'll need to instrument your code. You have to add listeners to the Discovery process, and dump information whenever mismatched QoS is noted by the middleware.
What happens if you use the Shapes demo? That's another "known-working DDS application".
Can you attach your demo code to this thread?
I now have the tools!
Shapes Demo has same behaviour.
Starting ping -publisher, in the Admin Console, health has a warning, "Topic contains only DataWriter(s)". Then I start ping -subscriber on another system, which displays in Admin Console as healthy, but of course still no data received. Still trying to learn to use the tools, but as always any pointers are appreciated.
Unfortunately, due to security constraints, attaching any demo code here isn't possible.
Thanks again for the help.
I'm at a loss.
Do you have access to Wireshark? That sits "between" the DDS layer, and the network stack above the firewall. If you run Wireshark on the subscriber side, and it doesn't see the data coming through from the publisher, then it is the network stack that is blocking the data somehow (either firewall, or multicast is disabled).
What happens if you set NDDS_DISCOVERY_PEERS to include the absolute IP address of the peer instead of multicast? You can use this as a guide: http://community.rti.com/content/forum-topic/configure-rti-connext-dds-not-use-multicast
I still think it's a firewall or multicast issue, since neither ping and shapes is shown to work in your environment.
Regards,
rip