# EXAMPLES

- Summary
- PingPong
- Tutorial
- HelloWorld
- WaitSet
- Listener
- ContentFilteredTopic
- QueryCondition
- Lifecycle
- Durability
- Ownership
- BuiltInTopics
- NetworkPartitions
- RoundTrip
- Throughput

## NetworkPartitions

### 1) Description

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.

### 2) Design

The 2 executables are :

- Chatter : sends messages to the chatbox
- MessageBoard : displays all available chatmessages

The 2 Networking Service configuration files, located in the etc directory, are :

- network1.xml : contains configuration to partition network traffic in the Partition "ChatRoom1" to the multicast address 239.0.0.1.
- network2.xml : contains configuration to partition network traffic in the Partition "ChatRoom1" to the multicast address 239.0.0.2.

The 2 DDSIE Service configuration files, located in the etc directory, are :

- ddsie1.xml : contains configuration to partition network traffic in the Partition "ChatRoom1" to the multicast address 239.0.0.3.
- ddsie2.xml : contains configuration to partition network traffic in the Partition "ChatRoom1" to the multicast address 239.0.0.4.

### 3) Scenario

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.

## Running the NetworkPartitions example

- Running examples in Posix
- Running examples in Visual Studio

### Running the examples in a Posix environment

#### Environment Setup

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.

- C++ Examples

#### C++ Executables

Building the examples is described on the Summary page

Two executables and a library are generated in the standalone directory when the example is built:

For C++

- Chatter
- MessageBoard
- libsacpp_networkpartition_types.so

#### Running the example using the Networking service

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

- The Vortex OpenSplice daemon should not be started manually. Instead the Vortex OpenSplice middleware and optional services are implicitly started by the single process applications as required.
- Open 2 or more terminals. Set up the environment and go to directory standalone as described above.
- Set the required configuraton file e.g. export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/network1.xml

Starting the MessageBoard and Chatter

- In the first terminal start a MessageBoard by running
  - export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/network1.xml
  - MessageBoard
- In a second terminal start another MessageBoard by running
  - export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/network2.xml
  - MessageBoard
- In a third terminal start a Chatter by running
  - export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/network1.xml
  - Chatter 1
- In a fourth terminal start a Chatter by running
  - export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/network2.xml
  - Chatter 2

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.

#### Running the example using the DDSIE service

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

- The Vortex OpenSplice daemon should not be started manually. Instead the Vortex OpenSplice middleware and optional services are implicitly started by the single process applications as required.
- Open 3 terminals. Setup the environment and go to directory standalone as described above.
- Set the required configuration file e.g. export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/ddsie1.xml

Starting the subscriber and publisher

- In the first terminal start a subscriber by running
  - export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/ddsie1.xml
  - MessageBoard
- In a second terminal start another subscriber by running
  - export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/ddsie2.xml
  - MessageBoard
- In a third terminal start a publisher by running
  - export OSPL_URI=file://$OSPL_HOME/examples/dcps/NetworkPartitions/etc/ddsie1.xml
  - Chatter 1

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.

### Running the example on Windows

#### Environment Setup

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 start menu. Alternatively, open a windows Command Prompt and execute the "OpenSplice_install_dir\release.bat" batch script supplied with the distribution.

- C++ Examples

#### C++ Executables

Building the examples is described on the Summary page

Two executables are generated in the standalone directory when the example is built:

For C++

- Chatter.exe
- Messageboard.exe

#### Running the example using the Networking service

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

- The Vortex OpenSplice daemon should not be started manually. Instead the Vortex OpenSplice middleware and optional services are implicitly started by the single process applications as required.
- Open 2 or more terminals. Set up the environment and go to directory standalone as described above.
- Set the required configuration file e.g. set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\network1.xml

Starting the MessageBoard and Chatter

- In the first terminal start a MessageBoard by running
  - set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\network1.xml
  - MessageBoard
- In a second terminal start another MessageBoard by running
  - set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\network2.xml
  - MessageBoard
- In a third terminal start a Chatter by running
  - set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\network1.xml
  - Chatter 1
- In a fourth terminal start a Chatter by running
  - set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\network2.xml
  - Chatter 2

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.

#### Running the example using the DDSIE service

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

- The Vortex OpenSplice daemon should not be started manually. Instead the Vortex OpenSplice middleware and optional services are implicitly started by the single process applications as required.
- Open 3 terminals. Set up the environment and go to directory standalone as described above.
- Set the required configuration file e.g. set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\ddsie1.xml

Starting the subscriber and publisher

- In the first terminal start a subscriber by running
  - set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\ddsie1.xml
  - MessageBoard
- In a second terminal start another subscriber by running
  - set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\ddsie2.xml
  - MessageBoard
- In a third terminal start a publisher by running
  - set OSPL_URI=file://%OSPL_HOME%\examples\dcps\NetworkPartitions\etc\ddsie1.xml
  - Chatter 1

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.