Sending a simple text message with Connext

Hello,

when you compile the example you should get two exectuables: HelloWorld_publisher and HelloWorld_subscriber. Run one on machine #1 and the other one in machine #2. If multicast is enabled and you are in the same LAN they should discover each other automatically.

If not you can set the NDDS_DISCOVERY_PEERS env. variable to point to the other machine.. (see section 4.1.2 in the Getting Started guide)

Let me know if it works :) 
   Gianpiero

Basic debugging for system-level DDS:

First:  Are they actually on the same network/subnetwork?

Two computers that are on a network may have different subnets (for example, one may be using a WiFi connection, the other wired, and these may be on different subnets, although a local switch is routing unicast without routing multicast, etc, etc, etc.  Be wary of Networking and Network Engineers, for they are crafty and prone to practical jokes).

[linux]$ ifconfig | grep inet

[Windows]c:\ ipconfig

Look for the inet addresses and determine if they have anything on the same subnet.  Warning! Windows machines that have more than four IP addresses (because of VMs, VPNs, etc) may result in pain and suffering!  Windows will arbitrarily re-order the interface list and RTI Connext DDS only selects (default) the first four it sees!  This means that sometimes it works, and sometimes it doesn't. 

Second:  You've determined that they have a mutual network subnet.  Now, will DDS work, at all?

Use rtiddsping[.exe].  The rtiddsping command-line tool is a pristine, known-working DDS application.  On one machine, run "rtiddsping[.exe] -publisher".  On the other machine, run "rtiddsping -subscriber".  If they do NOT see each other (look for "Found 1 additional ping subscriber(s)" on the publisher side, or "publisher(s)" on the subscriber side), then the problem is the network infrastructure, it is not RTI Connext DDS. 

If rtiddsping instances do not see each other, the possible causes are:

Multicast not enabled on either or both machines, or in an intervening router or switch.

A Firewall rule is configured to stop multicast packets, to not route UDP, or (more likely) is defaulting to stop unexpected port accesses (in which case you will need to manually enable the DDS discovery ports for the domain in use.  The default domain for rtiddsping is 0, which corresponds to ports 7400, 7401, 7410 and 7411.  Keep in mind that firewalls can be everywhere, you may need to enable ports/disable firewalls on the publisher side, on the subscriber side, AND any intervening routers or switches.

Third:  Ping works, does my application work?

After using -example <arch> with your IDL for MyFooType, you get a default publisher, and a default subscriber.  Compile these, without changing anything.  Run them. 

If they see each other, great!  This means that they are on the same Domain (because you didn't change anything), the Type is assignable (obviously, as they are using the same IDL), the Topic is the same (since you haven't changed it from the generated "Example MyFooType" topic) and QoS settings are compatible (again, because you haven't changed them from the defaults).  DDS is working, so now go forth, and Build Great Things!

If they do NOT see each other... hm.  In this case, run rtiddsspy.  The default domain in the example code is 0, so just run rtiddsspy without the -domainId <int> flag.  I recommend running it on both the publisher and the subscriber machine (one at a time).  In a working distributed system, you should see on either machine a "W +N" line (this is the publisher), and a "R +N" (the subscriber) line:

1408440707.896907  W +N  C0A80064    Example MyFooType           MyFooType         
1408440706.509978  R +N  C0A8006F    Example MyFooType           MyFooType

If you don't get those two lines (in this case, what you are probably getting is one line, depending on whether Spy is running on the publisher side ("W +N") or the subscriber side ("R +N").  If this is seen... post that here because that's pretty interesting.

Fourth:  You're well into developing your system, but now there's a publisher not seeing a subscriber (in an isolated case)

Check the following, using the tool described:

Can Spy see the publisher (from a machine that the publisher is not running on)

Can Spy see the subscriber (from a machine that the subscriber is not running on)

If this is the case, my guess is that the Topic is different (one may be "Example MyFooType" because the engineer forgot to change it to the one in use), or the Type is different and not assignable (because an engineer updated the IDL but failed to tell you this, and his new publisher is using the new type and your old subscriber is using the old type).  If the same Topic is given by both the publisher and the subscriber, but the Topic QoS or Type differs sufficiently, Spy will self-configure to agree with the first one it sees (arbitrary in a running system).  This may result in an incompatible datareader QoS.

Does Admin Tool show red flags for the Topic, the Type, the QoS or any other thing?  If it is not self-evident what the problem is at this point, post that here.

If at any time your steps are forced to diverge from the steps above, post that here, and I'll fix the above to agree with what you are seeing.