Using rtiddsping

Hi Todd

The purpose of allowing the configuration of the typeName and topicName is to provide flexibility in setting up less trivial scenarios. Say you wanted to setup a situation where one rtiddsping application is sending data to 2 subscribes and a separate rtiddsping publisher sends data to 3 rtiddsping subscribers. Using the -topicName  you can make each rtiddsping pubisher send data on a different TopicName and hence communicate only with the rtiddsping subscribers that use that same TopicName.  

This helps also test configurations of RTI technologies like the RTI Routing Service, the Recording Service, etc.

We also allow setting dfferent TypeNames as a way to test out scenarios where the TypeName affects the processing of the data. For example a RTI Routing Service can have routes configured to forward data based on the TypeName or a regular expression on the type name, etc.

That said, the 'scenario' creation capabilities of rtiddsping are quite limited. You cannot configure the schema of the data published or the values, or  publish more than one Topic, etc. etc. riddsping is really suited for very simple tests...

If what you want is to set up more complex scenarions and control the schema of the data publish, the number of topics, DataWriters and DataReaders, their QoS, the content of the data, or subscribe to multiple topics, or a mix, etc. We do provide a different tool called rtiddsprototyper which does all this and might fit what you are looking for. It is bundled with the regular RTI DDS distribution and can be found in the same directory as rtiddsping. Here is a quote from the RTI DDS Prototyper Getting Started Guide:

RTI Connext Prototyper is a tool to accelerate RTI Connext DDS application development and scenario testing. It provides RTI Connext DDS application developers with a quick and easy-to-use mechanism to try out realistic scenarios on their own computer systems and networks, and get immediate information on the expected performance, resource usage, and behavior of their system.

With the traditional approach, if you want to try a specific DDS distributed application design and determine Key Performance Indicators (KPIs), you would have to spend significant time and effort to develop a custom prototype that could determine KPIs such as:

• The memory a particular application is likely to use.
• The time it will take for discovery to complete.
• The system bandwidth the running application will consume.
• The CPU usage it will take for a particular application to publish its data at a certain rate, or to receive a certain set of Topics.
• The impact of changing data types, topics, Quality of Service, and other design parameters.

RTI DDS Prototyper significantly simplifies this process. Instead of writing custom code, you can:

1. Describe the system in an XML file (or files),
2. Run RTI DDS Prototyper on each computer, specifying the particular configuration for that computer, and
3. Observe the behavior of the running system and read the KPIs from the RTI Monitor tool.

Regards,

Gerardo

 Hi Todd,

Do you need this only in Windows?  We are working on some enhancements to rtiprototyper with scriptiing capabilities allowing you to handle the received data differently and examine it without necessarily printing to the console...  This will not be ready for a couple of months but we may be able to get you setup with some "experimental"  version as long as you only need it in a fairly standard platform and are willing to deal with experimental software...

As to the echo test. It is interesting. We had discussed internally in the past something that sounds similar.  The idea was to run N programs in different computers taht would ping each other and automatically report in a matrix the  matrix of latencies from each pair of computers.  Unfortunately we never had a good opportunity to resource this... But I am still hoping  we will get around to doing something like this soon... I think it is simple to do and would be quite useful...

Gerardo