Developers EMAIL:
Alessandro Bonfanti
Massimiliano Torregiani

sourceforge.net Logo

ISTRICE INTRO
Istrice intro What is Istrice ? In a nutshell, it is a system builds to allow a parallel and remote compilation of projects of any size. The typical scenario is that, whenever you have to compile a project, you run "make" and then you get a long coffee! We have to say as well that the host where the compilation is running are usually high loaded and hence not many resources are free for other tasks.Istrice addresses this problem allowing a host to demand the compilation to a set of remote hosts on the base of the choices got by a server that represents those hosts.

The key concepts of ISTRICE are: simple,dynamic, reconfigurable,powerful and parallelization. Ok, many words but how does it works really. Let's see thus the architecture of the Istrice project:


 

The logical units represented in the above figure are:

MS Master Server
it is the decisional unit of only ONE domain. It does not get any file to be compiled by itself but it decides the registered Second Layer Server (SLS, see below) to demand a compilation on the base of an algorithm that distributes the load due to the Client requests
SLS Second Layer Server  it plays the central role for compiling the source files on behalf of an Istrice Client (IC, see the following description). It receives the source from the Client and, after having compiled it, it returns the .o just produced
IC Istrice Client its preferred sentence is: “why should I do anything, if someone else can do it for me?” Actually the Istrice Client contacts the MS it is registered to, in order to know which SLS can compile its code. After that, the sole task it performs is to contact the indicated SLS and to send it the source to compile

Two other important concepts must be pointed out. First of all, the Domain concept: a domain is a group of units that are all registered to a MS that defines the domain. Some units belong to a domain to get its source files compiled (that is the ICs). We can call this sub-domain as Client Domain. The counterpart is the set of units that are registered to the MS in order to offer their services to compile the IC source files. We can call this complementary sub-domain as Server Domain.


This implies that there is a correspondence one-2-one between a MS and its controlled Domain.


At a "physical" point of view these logical units can live together within the same station (e.g. a station can be the client of the jth domain and the Master Server of the ith domain). The picture below figures out a possible scenario:

Does it seem a little mess? Maybe at a first sight but if each domain is considered singularly the scenario is simple enough (as we previously said). For shake of clearness, have a look to the Istrice configuration pages.

Seeing the Istrice architecture, we can justify our assertion that Istrice is dynamic and reconfigurable. In fact, any host can unregister itself to the belonged domain or can register to one or more domain either as SLS or as IC at any time, increasing the resources available to that domain. Furthermore it can build up a new domain launching a new MS instance.

Powerful and parallelization: this is true because each IC has at its disposal a whole domain of SLSs for distributing the compilation. To optimise this procedure, the MS manages the available resources by running an algorithm of Resource Allocation Control (RAC - see below).

Now have a look behind the scene of Istrice. How can all the Istrice units communicate among them? CORBA is the answer. By the way, Istrice uses OmniORB as the preferred implementation of ORB. Check out the pros and cons of using OnmiORB here (omniORB).

Furthermore, for configure the main characteristics of MS, SLS and IC we have employed configuration files formatted in XML. XML schemas grant the correctness of those files. To accomplish to this jobs, Istrice uses libxml2. Follow this link( libxml2) to have more information about.

Last but not the least, a short overview on the algorithms that are at the base of the RAC of the MS.

RAC is an open-loop system as shown in the figure below:


This means the RAC gets its decision scanning the SLS status list that contains the most recent state of each SLS of its domain. This list is periodically updated directly by SLSs that send their information to the MS which, in turn, inserts them into the list.

The algorithm employed by the RAC is chosen by the user at the initialisation of the MS. The possible algorithms are:

Load Balanced it tries to distribute the IC requests in order to maintain the load balanced among all the SLSs which belong to the domain
Max Load it assigns all the incoming requests to the same SLS till it becomes full
Task Balanced same as Load Balanced but it operates on the task not on the load
Max Tasks same as Max Load but it operates on the task not on the load
Tasks Weigh