The NetworkPartitions example is used to illustrate the concept of traffic partitioning using QoS settings and Vortex OpenSplice configuration. The example uses simplified versions of executables from the Tutorial example and four configuration files. Two of the configuration files cause the applications to use the Vortex OpenSplice Networking Service. The other two configuration files cause the applications to use the Vortex OpenSplice DDSIE service.
The 2 executables are :
The 2 Networking Service configuration files, located in the etc directory, are :
The 2 DDSIE Service configuration files, located in the etc directory, are :
The Chatter application publishes a number of chat messages to the Chat_ChatMessage Topic within the "ChatRoom1" Partition. The Partition name is defined in the Publisher QoS settings.
The MessageBoard application subscribes to the Chat_ChatMessage Topic within the "ChatRoom1" Partition. The Partition name is defined in the Subscriber QoS settings.
The configuration files allow the user to choose a multicast address for the applications that they run by setting their OSPL_URI environment variable to point to the appropriate file. The configuration achieves this by mapping all Topics in the Partition "ChatRoom1" to a NetworkPartition which defines the multicast address. This means that any data written into the "ChatRoom1" Partition will be directed to the multicast address defined within the configuration file.
The configuration files make the applications run in Single Process mode with Native Networking OR DDSIE.
Let's call OpenSplice_install_dir the Vortex OpenSplice installation directory.
The Vortex OpenSplice environment variables must be set in order for the examples to build/run correctly. To do this, open a terminal and source the "OpenSplice_install_dir/release.com" script supplied with the distribution.
Building the examples is described on the Summary page
Two executables are generated in the bin directory when the example is built:
For C++
Ensure that the environment for Vortex OpenSplice is set up correctly as described above for each new terminal used. Ensure that . is added to the LD_LIBRARY_PATH.
It is recommended that you run the MessageBoards and Chatters in separate terminals to avoid mixing the output.
The configuration files supplied with the example make the applications run in single process (heap memory) mode : the application starts the Vortex OpenSplice middleware
Starting the MessageBoard and Chatter
The Chatter executable supports an optional command-line parameter; an integer value [userid]. When this parameter is not specified, default values are used instead. When this parameter is supplied it will be used to uniquely identify the sender of the message. Transmit a message with userid = -1 to terminate the MessageBoard.
Subscribers and publishers that share the same configuration file will communicate as they join the same multicast group. If the configuration files differ then communication will not be established. For the above example the first instance of MessageBoard should only receive ChatMessages from the first instance of Chatter. This is because the Networking service decides upon the destination for data at write time, so the packets for the data that the publishing applications produce will be directed to the multicast address defined within the configuration. Note: There is currently a known issue for subscribers/publishers running on the same machine that means the subscriber will receive all data from publishers running on the machine regardless of the configuration used. To demonstrate the traffic partitioning it is currently necessary to use two machines, e.g. run step 1 and 3 above on one machine and step 2 and 4 on another.
Ensure that the environment for Vortex OpenSplice is set up correctly as described above for each new terminal used. Ensure that . is added to the LD_LIBRARY_PATH.
It is recommended that you run the subscriber and publisher in separate terminals to avoid mixing the output.
The configuration files supplied with the example make the applications run in single process (heap memory) mode : the application starts the Vortex OpenSplice middleware
Starting the subscriber and publisher
The Chatter executable supports an optional command-line parameter; an integer value [userid]. When this parameter is not specified, default values are used instead. When this parameter is supplied it will be used to uniquely identify the sender of the message. Transmit a message with userid = -1 to terminate the MessageBoard.
The DDSIE service pairs readers and writers over the network, so all subscribers and publishers will communicate regardless of the multicast address defined in their configuration (assuming they have matching QoS). The DDSIE will direct traffic as the configuration dictates. For the scenario described above this means that the packets for the data that is written by the publishing application produces will be directed to both multicast addresses. This can be checked using a network analysis tool such as Wireshark.
Let's call OpenSplice_install_dir the Vortex OpenSplice installation directory.
The Vortex OpenSplice environment variables must be set in order for the examples to run correctly. To do this open an Vortex OpenSplice Command Prompt which will set up the environment variables for Vortex OpenSplice automatically. The Vortex OpenSplice Command Prompt can be selected from the launcher. Alternatively, open a windows Command Prompt and execute the "OpenSplice_install_dir\release.bat" batch script supplied with the distribution.
Building the examples is described on the Summary page
Two executables are generated in the bin directory when the example is built:
For C++
Ensure that the environment for Vortex OpenSplice is set up correctly as described above for each new command prompt used.
The following steps describe how to run the examples:
The configuration files supplied with the example make the applications run in single process (heap memory) mode : the application starts the Vortex OpenSplice middleware
Starting the MessageBoard and Chatter
The Chatter executable supports an optional command-line parameter; an integer value [userid]. When this parameter is not specified, default values are used instead. When this parameter is supplied it will be used to uniquely identify the sender of the message. Transmit a message with userid = -1 to terminate the MessageBoard.
Subscribers and publishers that share the same configuration file will communicate as they join the same multicast group. If the configuration files differ then communication will not be established. For the above example the first instance of MessageBoard should only receive ChatMessages from the first instance of Chatter. This is because the Networking service decides upon the destination for data at write time, so the packets for the data that the publishing applications produce will be directed to the multicast address defined within the configuration.
Ensure that the environment for Vortex OpenSplice is set up correctly as described above for each new terminal used. Ensure that . is added to the LD_LIBRARY_PATH.
It is recommended that you run the subscriber and publisher in separate terminals to avoid mixing the output.
The configuration files supplied with the example make the applications run in single process (heap memory) mode : the application starts the Vortex OpenSplice middleware
Starting the subscriber and publisher
The Chatter executable supports an optional command-line parameter; an integer value [userid]. When this parameter is not specified, default values are used instead. When this parameter is supplied it will be used to uniquely identify the sender of the message. Transmit a message with userid = -1 to terminate the MessageBoard.
The DDSIE service pairs readers and writers over the network, so all subscribers and publishers will communicate regardless of the multicast address defined in their configuration (assuming they have matching QoS). The DDSIE will direct traffic as the configuration dictates. For the scenario described above this means that the packets for the data that is written by the publishing application produces will be directed to both multicast addresses. This can be checked using a network analysis tool such as Wireshark.