Overview
3
GRAS Library
OverviewOverview on the GRAS library
Introduction
This document introduce the GRAS library (Grid Reality And
Simulation, or according to my english dictionary,
Generally Recognized As Safe ;).
Here are the problems when you want to do so:
Communication in SG is done by passing tasks, while in
RL, you have to deal with sockets (or any wrapper to it).
In RL, each process should provide a main()
function, and it's obviously not the case in SG.
Application class target
If you want to run your code both in RL and in SG, you won't be
able to use the full set of features offered by any of those two
worlds. GRAS tries to provide a suffisent set of features to develop
your application, and implement them in both worlds.
GRAS uses the paradigm of event-driven
programming, which is an extension to the message-passing
one. Any process of a typical event-driven application declares
callback to incoming events, which can be messages from other
processes, timers or others.
All messages have an header, specifying its type, and attached
data, represented as one or several C structures. In order to send the
data over the network in RL, a type-description mecanism is provided, and
the RL version of GRAS implements XDR functionnalities. That is to say
that the data are converted to a intermediate representation before being
sent. A possible extension would be to use CDR, where data are sent in
the native format of the sender host, and converted on the destination
host only if needed, but this is still to do.
In order to not reimplement the wheel, GRAS use existing code, and
adapt them to make them work together. The SG version naturally use the
SimGrid toolkit, while the RL version is based over the communication
library used in NWSOnly the actual sending/receiving
features and formattypes features were taken from NWS. GRAS messaging
stuff is quite different from the NWS one, which was not easily adaptable
in SG as is.. That's why we will now present the NWS
project in order to give you a better understanding of its internals used
here.
The Network Weather Service and its "portability" library
The purpose of the NWS project is to provide any kind of usefull
information about the availability of a Grid platform. like the CPU load,
free memory and disk of all hosts, the bandwidth and latency between each
host pair, and so on. It is also able to predict the future trend of each
value by applying some statistical treatement to the measurements.
In order to achieve this goal, the NWS system is composed of four
kind of processes:
Sensors: those process are in charge or realizing the
actual measurement needed by the system.
Memory servers: they store on disk the result of the experiments
conducted by the sensors for a later use.
Forecasters: when a client application asks to, the
forecasters retrieves the measurements from the memory servers, apply
the needed statistical treatement, and then inform the client of the
predicted variations.
NameServer: Every process in the NWS system have to
register itself to the nameserver, so that any process looks for another
element, it can find the answer by asking to the nameserver.
As you can see, this system is distributed by nature, and its
authors builded a specific toolbox they call the portability library. It
contains a great quantity of cool stuff to do various kind of things. The
main part is a very high level messaging library, where processes declare
callbacks to strongly typed messages sent from other processes.
One of the limitation of this system is that even if processes can
ear to several sockets, all messages received from the different sources
are mixed together and handled by the same control loop. GRAS inherit
this limitation, but in fact, we don't think that it's really limitating,
thanks to the fact that messages are strongly typed.
The philosophy of this library constitues the heart of GRAS, which
actually provide the same kind of features.