Sending a simple text message with Connext

5 posts / 0 new
Last post
Offline
Last seen: 5 years 3 weeks ago
Joined: 02/27/2014
Posts: 15
Sending a simple text message with Connext

with assistance from G-d

Although it may be simple,

how do I send a simple message from one computer to another,

for example, let's take the HelloWorld example

(referred to in 

RTI Data Distribution Service
Core Libraries and Utilities
Getting Started Guide

4.3.2 (page 57-65))

if I have built and run the example, 

and everything works fine.

Now - how do I open a subscriber on a different computer (which is in the same LAN),

in a way that when I publish the data on the first computer,

I will get the data onthe subscriber window which opened on the other computer?

I know this is very basic, yet I haven't a clue!

Organization:
gianpiero's picture
Offline
Last seen: 5 months 2 weeks ago
Joined: 06/02/2010
Posts: 174

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

 

Offline
Last seen: 5 years 3 weeks ago
Joined: 02/27/2014
Posts: 15

I haven't diasbled the multicast.

And I work with Windows OS

(I understood that there is no need to set the NDDS_DISCOVERY_PEERS env. var. in this OS).

and yet it didn't work.

what else can I do?

rip
rip's picture
Offline
Last seen: 1 month 2 weeks ago
Joined: 04/06/2012
Posts: 315

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.

 

Offline
Last seen: 5 years 3 weeks ago
Joined: 02/27/2014
Posts: 15

What a great answer,

I must say, it's amazing 

how you put it all neatly and clearly

in-depth!

 

Surely enough, one computer is connected by WIFI

and the other by Ethernet (wired).

 

Although, I got my answer straight at the start,

I'm sure your answer will be very useful for others and myself

in order to detect failures in connectivity.

Thank-you for the effort and good thought you made in responding.

 

May G-d bless those who choose to do good with all their heart!