4

I have a problem getting the RTI Routing Service to work with my applications.

I have created a simple DDS publisher application and a simple DDS subscriber application. The applications communicate while running on 2 different computers over LAN, but I cant get them to work over WAN using the RTI Routing Service.

I followed the "Example 8 - Using the TCP Transport with Routing Service" in "RTI Routing Service - Getting Started Guide". And I can get the RTI Shapes Demo to run over the RTI Routing Service. NB. My applications use the same Domain IDs as the RTI Shapes Demo

My publisher is on PC1 and the subscriber is on PC2. I can see (using rtiddsspy) that PC2 receives data from the RTI Routing Service, but the subscriber application does not get notified on PC2.

Is there something that I have to especially aware of, when creating DDS applications for use over the RTI Routing Service?

Regards John

Reinier Torenbeek
  • 16,669
  • 7
  • 46
  • 69
Rauhe
  • 77
  • 8

1 Answers1

4

I can see (using rtiddsspy) that PC2 receives data from the RTI Routing Service, but the subscriber application does not get notified on PC2.

From this information, I would say that the most likely cause is a mismatch in QoS settings between the routing service publisher and your application subscriber. You could verify this in several ways:

  • Use the Analyzer tool (if you have it at your disposal) while your system is running. It can show you the QoS settings used on each entity, as well as do QoS matching analysis to uncover mismatches.
  • Use the default QoS settings with your application DataReader, so it will be less likely to conflict with any of your Routing Service QoS settings. If your DataReader receives data after that adjustment, then you know that conflicting QoS settings was the cause.

The default QoS settings used by spy are less likely to cause these kinds of mismatches, which is the reason why spy does receive the messages.

For your reference, you can check out this QoS Policy Reference Guide / Cheat-sheet. On the first page, any QoS that has a Y in the RxO column could potentially cause a mismatch.

Reinier Torenbeek
  • 16,669
  • 7
  • 46
  • 69
  • That was exactly what the problem was. I changed the QoS parameters for the RTI Routing Service and it worked perfectly. Thank you! Could you tell me if it is possible, to configure the RTI Routing Service, to automatically mimic the QoS parameter of any DataReader or DataWriter in the system? i.e instead of manually setting QoS parameters in the Routing Service to correspond to the DataReaders or DataWriters in the system, then the Routing Service could do it itself? – Rauhe Apr 26 '13 at 12:04
  • It is currently not possible to automatically mimic the QoS parameters like that. I know this has been considered before, but has not been planned (yet) to be implemented. On the one hand, that might be a convenient extension which would have avoided your issue. On the other hand, it could be a risky approach. Suppose that some DataReader accidentally uses the wrong QoS setting. If the Routing Service discovers that DataReader first, it will mimic the incorrect settings, with possible system-wide consequences. – Reinier Torenbeek Apr 27 '13 at 03:33
  • OK, good to know the background for the implementation. Thank you very much for the information :) – Rauhe Apr 27 '13 at 07:22