Overview 3 GRAS Library OverviewOverview on the GRAS library 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. 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 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.