+++ /dev/null
-<refentry id="gras-overview">
-<refmeta>
-<refentrytitle>Overview</refentrytitle>
-<manvolnum>3</manvolnum>
-<refmiscinfo>GRAS Library</refmiscinfo>
-</refmeta>
-
-<refnamediv>
-<refname>Overview</refname><refpurpose>Overview on the GRAS library</refpurpose>
-</refnamediv>
-
-<refsect1>
-<title>Introduction</title>
-<para>This document introduce the GRAS library (<emphasis>Grid Reality And
- Simulation</emphasis>, or according to my english dictionary,
- <emphasis>Generally Recognized As Safe</emphasis> ;).</para>
-
-<para>Here are the problems when you want to do so:
- <itemizedlist>
- <listitem>
- <para>Communication in SG is done by passing tasks, while in
- RL, you have to deal with sockets (or any wrapper to it).</para>
- </listitem>
- <listitem><para>In RL, each process should provide a main()
- function, and it's obviously not the case in SG.</para>
- </listitem>
- </itemizedlist>
-</para>
-</refsect1>
-
-<refsect1>
- <title>Application class target</title>
- <para>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.</para>
-
- <para>GRAS uses the paradigm of <emphasis>event-driven
- programming</emphasis>, 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.</para>
-
- <para>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.</para>
-
- <para>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 NWS<footnote><para>Only 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.</para></footnote>. That's why we will now present the NWS
- project in order to give you a better understanding of its internals used
- here.</para>
-</refsect1>
-
-<refsect1>
- <title>The Network Weather Service and its "portability" library</title>
-
- <para>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.</para>
-
- <para>In order to achieve this goal, the NWS system is composed of four
- kind of processes:
- <itemizedlist>
- <listitem><para>Sensors: those process are in charge or realizing the
- actual measurement needed by the system.</para></listitem>
-
- <listitem><para>Memory servers: they store on disk the result of the experiments
- conducted by the sensors for a later use.</para></listitem>
-
- <listitem><para>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.</para></listitem>
-
- <listitem><para>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.</para></listitem>
- </itemizedlist></para>
-
- <para>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.</para>
-
- <para>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.</para>
-
- <para>The philosophy of this library constitues the heart of GRAS, which
- actually provide the same kind of features.</para>
-
-</refsect1>
-
-</refentry>
