| Next: Tutorial: Distributed computing - Use authentication mechanisms to secure your Framework |
|---|
Prerequisites
This tutorial assumes that you know how to create configuration files and launch a framework using these files via mira, miragui or miracenter.
Introduction
In this tutorial we will learn how to distribute a single application (consisting of several units) across multiple processes or even multiple systems in a network. This means we will split a single configuration file into multiple ones, where each file contains a subset of the units of our application. Each configuration file is then used to launch the contained units in a separate process. All processes (frameworks) will work together using network connections to provide the same functionality as the original application.
The initial configuration
The following code will form the XML configuration file of our application that we like to distribute across multiple processes. Just paste that code into a file and save it as OneProcess.xml in your tutorial or demo folder.
Our application consists of two units that come with the MIRA installation and can be found in [MIRA ROOT]/framework/examples/fw/IntPublisherSubscriber. One produces a continuously increasing integer value that it writes to a channel called "Int". The other unit is a consumer that just subscribes to that channel and writes its content to the console. This configuration can be launched with the mira tool and debug level >= 3 (via the -d or –debug parameter) and should produce the following output:
Splitting it up
Since our application has only two units, we will split it into two processes. Just create a PublisherProcess.xml file with the following content:
and a SubscriberProcess.xml file that looks like:
Now we have two configuration files - one that launches our publisher unit and one launching our subscriber unit. Each configuration can be started using the mira tool like we have done before. But right now there would be no connection between these, so the subscriber will not receive any data and therefore not print anything.
Putting it back together
In MIRA, we have no single server were each Framework connects to. Instead, each mira tool can act either as a server where other Frameworks connect to and/or a client that connects to other Frameworks. In our case, we need to decide which configuration we launch as a server and which as a client. We will start the Framework that contains the publisher as server and the one that contains the subscriber as client.
To that purpose, we need to change the way we execute mira. For the publisher, we need to specify a port the Framework listens on for incoming connections from other Frameworks. We chose 1234 as port and specify it via the -p or –fw-port parameter:
Now the first Framework is started and our publisher is already working. We need to keep this Framework running while opening another console. On the new console we start our second Framework that acts as a client and contains our subscriber. We need to specify the addresses of all the Frameworks we like to connect to. Since we are running on the same system the address is our local host (127.0.0.1) and the port is 1234 as we have defined before. We tell mira about this known Framework via the -k or –known-fw parameter. This parameter takes a comma separated list of all known Frameworks with syntax HOST:PORT (don't forget to set the right debug level)
Notice that our publisher was already running for a while so it already increased its integer value several times.
| When connecting Frameworks that are located on different systems in a network, it may be necessary to allow connections to pass your firewall. This is ONLY needed on the server side, e.g. by opening the firewall for the used ports on the system that runs a Framework that acts as a server. |
Adapting the configuration files
To omit typing the port and known framework address each time we start mira, we can store these details in the configuration files. Edit the PublisherProcess.xml file and add a XML configuration node for the communication part of the Framework:
Now we can start the publisher without specifying a port each time.
To adapt the subscriber configuration edit the SubscriberProcess.xml file so that it looks like:
Now when launching this configuration the framework will try to connect to the given address without the need of the -k or –known-fw parameter.
|
| The port given via command line will overwrite any port specified in the configuration file. Known frameworks given on the command line will be added to the list of known frameworks like the ones specified in the configuration file and will NOT overwrite them. |
| Next: Tutorial: Distributed computing - Use authentication mechanisms to secure your Framework |
|---|
