1 <refentry id="gras-overview">
3 <refentrytitle>Overview</refentrytitle>
4 <manvolnum>3</manvolnum>
5 <refmiscinfo>GRAS Library</refmiscinfo>
9 <refname>Overview</refname><refpurpose>Overview on the GRAS library</refpurpose>
13 <title>Introduction</title>
14 <para>This document introduce the GRAS library (<emphasis>Grid Reality And
15 Simulation</emphasis>, or according to my english dictionary,
16 <emphasis>Generally Recognized As Safe</emphasis> ;).</para>
18 <para>Here are the problems when you want to do so:
21 <para>Communication in SG is done by passing tasks, while in
22 RL, you have to deal with sockets (or any wrapper to it).</para>
24 <listitem><para>In RL, each process should provide a main()
25 function, and it's obviously not the case in SG.</para>
32 <title>Application class target</title>
33 <para>If you want to run your code both in RL and in SG, you won't be
34 able to use the full set of features offered by any of those two
35 worlds. GRAS tries to provide a suffisent set of features to develop
36 your application, and implement them in both worlds.</para>
38 <para>GRAS uses the paradigm of <emphasis>event-driven
39 programming</emphasis>, which is an extension to the message-passing
40 one. Any process of a typical event-driven application declares
41 callback to incoming events, which can be messages from other
42 processes, timers or others.</para>
44 <para>All messages have an header, specifying its type, and attached
45 data, represented as one or several C structures. In order to send the
46 data over the network in RL, a type-description mecanism is provided, and
47 the RL version of GRAS implements XDR functionnalities. That is to say
48 that the data are converted to a intermediate representation before being
49 sent. A possible extension would be to use CDR, where data are sent in
50 the native format of the sender host, and converted on the destination
51 host only if needed, but this is still to do.</para>
53 <para>In order to not reimplement the wheel, GRAS use existing code, and
54 adapt them to make them work together. The SG version naturally use the
55 SimGrid toolkit, while the RL version is based over the communication
56 library used in NWS<footnote><para>Only the actual sending/receiving
57 features and formattypes features were taken from NWS. GRAS messaging
58 stuff is quite different from the NWS one, which was not easily adaptable
59 in SG as is.</para></footnote>. That's why we will now present the NWS
60 project in order to give you a better understanding of its internals used
65 <title>The Network Weather Service and its "portability" library</title>
67 <para>The purpose of the NWS project is to provide any kind of usefull
68 information about the availability of a Grid platform. like the CPU load,
69 free memory and disk of all hosts, the bandwidth and latency between each
70 host pair, and so on. It is also able to predict the future trend of each
71 value by applying some statistical treatement to the measurements.</para>
73 <para>In order to achieve this goal, the NWS system is composed of four
76 <listitem><para>Sensors: those process are in charge or realizing the
77 actual measurement needed by the system.</para></listitem>
79 <listitem><para>Memory servers: they store on disk the result of the experiments
80 conducted by the sensors for a later use.</para></listitem>
82 <listitem><para>Forecasters: when a client application asks to, the
83 forecasters retrieves the measurements from the memory servers, apply
84 the needed statistical treatement, and then inform the client of the
85 predicted variations.</para></listitem>
87 <listitem><para>NameServer: Every process in the NWS system have to
88 register itself to the nameserver, so that any process looks for another
89 element, it can find the answer by asking to the nameserver.</para></listitem>
90 </itemizedlist></para>
92 <para>As you can see, this system is distributed by nature, and its
93 authors builded a specific toolbox they call the portability library. It
94 contains a great quantity of cool stuff to do various kind of things. The
95 main part is a very high level messaging library, where processes declare
96 callbacks to strongly typed messages sent from other processes.</para>
98 <para>One of the limitation of this system is that even if processes can
99 ear to several sockets, all messages received from the different sources
100 are mixed together and handled by the same control loop. GRAS inherit
101 this limitation, but in fact, we don't think that it's really limitating,
102 thanks to the fact that messages are strongly typed.</para>
104 <para>The philosophy of this library constitues the heart of GRAS, which
105 actually provide the same kind of features.</para>