+experimental and are likely to disappear without notice... To know the
+list of the currently implemented models, you should use the
+--help-models command line option.
+
+\verbatim
+./masterslave_forwarder ../small_platform.xml deployment_masterslave.xml --help-models
+Long description of the workstation models accepted by this simulator:
+ CLM03: Default workstation model, using LV08 and CM02 as network and CPU
+ compound: Workstation model allowing you to use other network and CPU models
+ ptask_L07: Workstation model with better parallel task modeling
+Long description of the CPU models accepted by this simulator:
+ Cas01_fullupdate: CPU classical model time=size/power
+ Cas01: Variation of Cas01_fullupdate with partial invalidation optimization of lmm system. Should produce the same values, only faster
+ CpuTI: Variation of Cas01 with also trace integration. Should produce the same values, only faster if you use availability traces
+Long description of the network models accepted by this simulator:
+ Constant: Simplistic network model where all communication take a constant time (one second)
+ CM02: Realistic network model with lmm_solve and no correction factors
+ LV08: Realistic network model with lmm_solve and these correction factors: latency*=10.4, bandwidth*=.92, S=8775
+ Reno: Model using lagrange_solve instead of lmm_solve (experts only)
+ Reno2: Model using lagrange_solve instead of lmm_solve (experts only)
+ Vegas: Model using lagrange_solve instead of lmm_solve (experts only)
+\endverbatim
+
+\subsection faq_tracing Tracing Simulations for Visualization
+
+The trace visualization is widely used to observe and understand the behavior
+of parallel applications and distributed algorithms. Usually, this is done in a
+two-step fashion: the user instruments the application and the traces are
+analyzed after the end of the execution. The visualization itself can highlights
+unexpected behaviors, bottlenecks and sometimes can be used to correct
+distributed algorithms. The SimGrid team is currently instrumenting the library
+in order to let users trace their simulations and analyze them. This part of the
+user manual explains how the tracing-related features can be enabled and used
+during the development of simulators using the SimGrid library.
+
+\subsubsection faq_tracing_howitworks How it works
+
+For now, the SimGrid library is instrumented so users can trace the <b>platform
+utilization</b> using the MSG interface. This means that the tracing will
+register how much power is used for each host and how much bandwidth is used for
+each link of the platform. The idea with this type of tracing is to observe the
+overall view of resources utilization in the first place, especially the
+identification of bottlenecks, load-balancing among hosts, and so on.
+
+The idea of the instrumentation is to classify the MSG tasks by category,
+and trace
+the platform utilization (hosts and links) for each of the categories. For that,
+the tracing interface enables the declaration of categories and a function to
+mark a task with a previously declared category. <em>The tasks that are not
+classified according to a category are not traced</em>.
+
+\subsubsection faq_tracing_enabling Enabling using CMake
+
+With the sources of SimGrid, it is possible to enable the tracing
+using the parameter <b>-Dtracing=on</b> when the cmake is executed.
+The section \ref faq_tracing_functions describes all the functions available
+when this Cmake options is activated. These functions will have no effect
+if SimGrid is configured without this option (they are wiped-out by the
+C-preprocessor).
+
+\verbatim
+$ cmake -Dtracing=on .
+$ make
+\endverbatim
+
+\subsubsection faq_tracing_functions Tracing Functions
+
+\subsubsubsection Mandatory Functions
+
+\li <b>\c TRACE_start ()</b>: This is the first function to
+be called. It returns 0 if everything was properly initialized, 1 otherwise.
+All trace functions called before TRACE_start do nothing.
+
+\li <b>\c TRACE_category (const char *category)</b>: This function should be used
+to define a user category. The category can be used to differentiate the tasks
+that are created during the simulation (for example, tasks from server1,
+server2, or request tasks, computation tasks, communication tasks).
+All resource utilization (host power and link bandwidth) will be
+classified according to the task category. Tasks that do not belong to a
+category are not traced.
+
+\li <b>\c TRACE_msg_set_task_category (m_task_t task, const char *category)</b>:
+This function should be called after the creation of a task, to define the
+category of that task. The first parameter \c task must contain a task that was
+created with the function \c MSG_task_create. The second parameter
+\c category must contain a category that was previously defined by the function
+\c TRACE_category.
+
+\li <b>\c TRACE_end ()</b>: This is the last function to be called. It closes
+the trace file and stops the tracing of the simulation. All tracing will be
+completely disabled after the calling this function. Although we recommend
+the use of this function somewhere in the end of program, it can be used
+anywhere in the code. This function returns 0 if everything is ok, 1 otherwise.
+
+\subsubsubsection Optional Functions
+
+\li <b>\c TRACE_host_variable_declare (const char *variable)</b>:
+Declare a user variable that will be associated to hosts. A variable can
+be used to trace user variables such as the number of tasks in a server,
+the number of clients in an application, and so on.
+
+\li <b>\c TRACE_host_variable_[set|add|sub] (const char *variable, double
+value)</b>:
+Set the value of a given user variable. It is important to remind that
+the value of this variable is always associated to the host. The host
+that will be used when these functions are called is the one returned by
+the function \c MSG_host_self().
+
+\subsubsection faq_tracing_options Tracing configuration Options
+
+These are the options accepted by the tracing system of SimGrid:
+
+\li <b>\c tracing/filename</b>: use this to specify the name of the trace file
+that will be created during the simulation. For example, after the binary
+of your simulator, you can pass as parameter this:
+\verbatim
+--cfg=tracing/filename:mytracefile.trace
+\endverbatim
+in order to trace the behavior of the simulation in a file with the name
+mytracefile.trace.
+
+\li <b>\c tracing/platform</b>: use this to activate the tracing of the
+platform. For example, you can pass as parameter to your simulator:
+\verbatim
+--cfg=tracing/platform:1
+\endverbatim
+to trace the platform utilization by the categories you declared in your
+simulator. By default, this options is set to 0.
+
+\subsubsection faq_tracing_example Example of Instrumentation
+
+A simplified example using the tracing mandatory functions.
+
+\verbatim
+int main (int argc, char **argv)
+{
+ MSG_global_init (&argc, &argv);
+
+ //note that TRACE_start must be called after MSG_global_init
+ TRACE_start ();
+ TRACE_category ("request");
+ TRACE_category ("computation");
+ TRACE_category ("finalize");
+
+ //(... after deployment ...)
+
+ m_task_t req1 = MSG_task_create("1st_request_task", 10, 10, NULL);
+ m_task_t req2 = MSG_task_create("2nd_request_task", 10, 10, NULL);
+ m_task_t req3 = MSG_task_create("3rd_request_task", 10, 10, NULL);
+ m_task_t req4 = MSG_task_create("4th_request_task", 10, 10, NULL);
+ TRACE_msg_set_task_category (req1, "request");
+ TRACE_msg_set_task_category (req2, "request");
+ TRACE_msg_set_task_category (req3, "request");
+ TRACE_msg_set_task_category (req4, "request");
+
+ m_task_t comp = MSG_task_create ("comp_task", 100, 100, NULL);
+ TRACE_msg_set_task_category (comp, "computation");
+
+ m_task_t finalize = MSG_task_create ("finalize", 0, 0, NULL);
+ TRACE_msg_set_task_category (finalize, "finalize");
+
+ //(...)
+
+ MSG_clean();
+
+ TRACE_end();
+ return 0;
+}
+\endverbatim
+
+\subsubsection faq_tracing_analyzing Analyzing the SimGrid Traces
+
+The SimGrid library, during an instrumented simulation, creates a trace file in
+the Paje file format that contains the platform utilization for the simulation
+that was executed. The visualization analysis of this file is performed with the
+visualization tool <a href="http://triva.gforge.inria.fr">Triva</a>, with
+special configurations tunned to SimGrid needs. This part of the documentation
+explains how to configure and use Triva to analyse a SimGrid trace file.
+
+- <b>Installing Triva</b>: the tool is available in the INRIAGforge,
+at <a href="http://triva.gforge.inria.fr">http://triva.gforge.inria.fr</a>.
+Use the following command to get the sources, and then check the file
+<i>INSTALL.simplified</i>. This file contains instructions to install
+the tool's dependencies in a Ubuntu/Debian Linux.
+\verbatim
+$ svn checkout svn://scm.gforge.inria.fr/svn/triva
+$ cd triva
+$ cat INSTALL.simplified
+\endverbatim
+
+- <b>Executing Triva</b>: a binary called <i>Triva</i> is available after the
+ installation (you can execute it passing <em>--help</em> to check its
+options). If the triva binary is not available after following the
+installation instructions, you may want to execute the following command to
+initialize the GNUstep environment variables (note that the location of the
+<i>GNUstep.sh</i> file may vary depending on your GNUstep installation - the
+command is known to work in Ubuntu and Debian Linux):
+\verbatim
+$ source /usr/share/GNUstep/Makefiles/GNUstep.sh
+\endverbatim
+You should be able to see this output after the installation of triva:
+\verbatim
+$ ./Triva.app/Triva --help
+Usage: Triva [OPTION...] TRACEFILE
+Trace Analysis through Visualization
+
+ You need to use one of the following options:
+ -g, --graph Graph Analysis
+ -t, --treemap Treemap Analysis
+
+ Other auxiliary options to check the trace file:
+ -c, --check Check the integrity of trace file
+ -h, --hierarchy Export the trace type hierarchy
+ -l, --list List entity types
+
+ -?, --help Give this help list
+ --usage Give a short usage message
+\endverbatim
+Triva expects that the user choose one of the available options
+(currently <em>--graph</em> or <em>--treemap</em> for a visualization analysis)
+and the trace file from the simulation.
+
+- <b>Understanding Triva - time-slice</b>: the analysis of a trace file using
+ the tool always takes into account the concept of the <em>time-slice</em>.
+This concept means that what is being visualized in the screen is always
+calculated considering a specific time frame, with its beggining and end
+timestamp. The time-slice is configured by the user and can be changed
+dynamically through the window called <em>Time Interval</em> that is opened
+whenever a trace file is being analyzed. The next figure depicts the time-slice
+configuration window.
+In the top of the window, in the space named <i>Trace Time</i>,
+the two fields show the beggining of the trace (which usually starts in 0) and
+the end (that depends on the time simulated by SimGrid). The middle of the
+window, in the square named <i>Time Slice Configuration</i>, contains the
+aspects related to the time-slice, including its <i>start</i> and its
+<i>size</i>. The gray rectangle in the bottom of this part indicates the
+<i>current time-slice</i> that is considered for the drawings. If the checkbox
+<i>Update Drawings on Sliders Change</i> is not selected, the button
+<i>Apply</i> must be clicked in order to inform triva that the
+new time-slice must be considered. The bottom part of the window, in the space
+indicated by the square <i>Time Slice Animation</i> can be used to advance
+the time-frame automatically. The user configures the amount of time that the
+time-frame will forward and how frequent this update will happen. Once this is
+configured, the user clicks the <i>Play</i> button in order to see the dynamic
+changes on the drawings.
+<center>
+\htmlonly
+<a href="triva-time_interval.png" border=0><img src="triva-time_interval.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+<b>Remarks:</b> when the trace has too many hosts or links, the computation to
+take into account a new time-slice can be expensive. When this happens, the
+<i>Frequency</i> parameter, but also updates caused by change on configurations
+when the checkbox <i>Update Drawings on Sliders
+Change</i> is selected will not be followed.
+
+- <b>Understanding Triva - graph</b>: this part of the documention explains how
+ to analyze the traces using the graph view of Triva, when the user executes
+the tool passing <em>--graph</em> as parameter. Triva opens three windows when
+this parameter is used: the <i>Time Interval</i> window (previously described),
+the <i>Graph Representation</i> window, and the <em>Graph Configuration</em>
+window. The Graph Representation is the window where drawings take place.
+Initially, it is completely white waiting for a proper graph configuration input
+by the user. We start the description of this type of analysis by describing the
+<i>Graph Configuration</i> window (depicted below). By using a particular
+configuration, triva
+can be used to customize the graph drawing according to
+the SimGrid trace that was created with user-specific categories. Before delving
+into the details of this customization, let us first explain the major parts of
+the graph configuration window. The buttons located in the top-right corner can
+be used to delete, copy and create a new configuration. The checkbox in the
+top-middle part of the window indicates if the configuration typed in the
+textfield is syntactically correct (we are using the non-XML
+<a href="http://en.wikipedia.org/wiki/Property_list">Property List Format</a> to
+describe the configuration). The pop-up button located on the top-left corner
+indicates the selected configuration (the user can have multiple graph
+configurations). The bottom-left text field contains the name of the current
+configuration (updates on this field must be followed by typing enter on the
+keyboard to take into account the name change). The bottom-right <em>Apply</em>
+button activates the current configuration, resulting on an update on the graph
+drawings.
+<center>
+\htmlonly
+<a href="triva-graph_configuration.png" border=0><img src="triva-graph_configuration.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+<b>Basic SimGrid Configuration</b>: The figure shows in the big textfield the
+basic configuration that should be used during the analysis of a SimGrid trace
+file. The basic logic of the configuration is as follows:
+\verbatim
+{
+ node = (HOST);
+ edge = (LINK);
+\endverbatim
+The nodes of the graph will be created based on the <i>node</i> parameter, which
+in this case is the different <em>"HOST"</em>s of the platform
+used to simulate. The <i>edge</i> parameter indicates that the edges of the
+graph will be created based on the <em>"LINK"</em>s of the platform. After the
+definition of these two parameters, the configuration must detail how
+<em>HOST</em>s and <em>LINK</em>s should be drawn. For that, the configuration
+must have an entry for each of the types used. For <em>HOST</em>, as basic
+configuration, we have:
+\verbatim
+ HOST = {
+ size = power;
+ scale = global;
+ };
+\endverbatim
+The parameter <em>size</em> indicates which variable from the trace file will be
+used to define the size of the node HOST in the visualization. If the simulation
+was executed with availability traces, the size of the nodes will be changed
+according to these traces. The parameter <em>scale</em> indicates if the value
+of the variable is <em>global</em> or <em>local</em>. If it is global, the value
+will be relative to the power of all other hosts, if it is local, the value will
+be relative locally.
+For <em>LINK</em> we have:
+\verbatim
+ LINK = {
+ src = source;
+ dst = destination;
+
+ size = bandwidth;
+ scale = global;
+ };
+\endverbatim
+For the types specified in the <em>edge</em> parameter (such as <em>LINK</em>),
+the configuration must contain two additional parameters: <em>src</em> and
+<em>dst</em> that are used to properly identify which nodes this edge is
+connecting. The values <em>source</em> and <em>destination</em> are always present
+in the SimGrid trace file and should not be changed in the configuration. The
+parameter <em>size</em> for the LINK, in this case, is configured as the
+variable <em>bandwidth</em>, with a <em>global</em> scale. The scale meaning
+here is exactly the same used for nodes. The last parameter is the GraphViz
+algorithm used to calculate the position of the nodes in the graph
+representation.
+\verbatim
+ graphviz-algorithm = neato;
+}
+\endverbatim
+<b>Customizing the Graph Representation</b>: triva is capable to handle
+a customized graph representation based on the variables present in the trace
+file. In the case of SimGrid, every time a category is created for tasks, two
+variables in the trace file are defined: one to indicate node utilization (how
+much power was used by that task category), and another to indicate link
+utilization (how much bandwidth was used by that category). For instance, if the
+user declares a category named <i>request</i>, there will be variables named
+<b>p</b><i>request</i> and a <b>b</b><i>request</i> (<b>p</b> for power and
+<b>b</b> for bandwidth). It is important to notice that the variable
+<i>prequest</i> in this case is only available for HOST, and
+<i>brequest</i> is only available for LINK. <b>Example</b>: suppose there are
+two categories for tasks: request and compute. To create a customized graph
+representation with a proportional separation of host and link utilization, use
+as configuration for HOST and LINK this:
+\verbatim
+ HOST = {
+ size = power;
+ scale = global;
+
+ sep_host = {
+ type = separation;
+ size = power;
+ values = (prequest, pcomputation);
+ };
+ };
+
+ LINK = {
+ src = source;
+ dst = destination;
+ size = bandwidth;
+ scale = global;
+
+ sep_link = {
+ type = separation;
+ size = bandwidth;
+ values = (brequest, bcomputation);
+ };
+ };
+\endverbatim
+Where <i>sep_host</i> contains a composition of type <i>separation</i> where
+its max size is the <i>power</i> of the host and the variables <i>prequest</i>
+and <i>pcomputation</i> are drawn proportionally to the size of the HOST. And
+<i>sep_link</i> is also a separation where max is defined as the
+<i>bandwidth</i> of the link, and the variables <i>brequest</i> and
+<i>bcomputation</i> are drawn proportionally within a LINK.
+<i>This configuration enables the analysis of resource utilization by MSG tasks,
+and the identification of load-balancing issues, network bottlenecks, for
+instance.</i> \n
+<b>Other compositions</b>: besides <i>separation</i>, it is possible to use
+other types of compositions, such as gradients, and colors, like this:
+\verbatim
+ gra_host = {
+ type = gradient;
+ scale = global;
+ values = (numberOfTasks);
+ };
+ color_host = {
+ type = color;
+ values = (is_server);
+ };
+\endverbatim
+Where <i>gra_host</i> creates a gradient within a node of the graph, using a
+global scale and using as value a variable called <i>numberOfTasks</i>, that
+could be declared by the user using the optional tracing functions of SimGrid.
+If scale is global, the max and min value for the gradient will be equal to the
+max and min numberOfTasks among all hosts, and if scale is local, the max and
+min value based on the value of numberOfTasks locally in each host.
+And <i>color_host</i> composition draws a square based on a positive value of
+the variable <i>is_server</i>, that could also be defined by the user using the
+SimGrid tracing functions. \n
+<b>The Graph Visualization</b>: The next figure shows a graph visualization of a
+given time-slice of the masterslave_forwarder example (present in the SimGrid
+sources). The red color indicates tasks from the <i>compute</i> category. This
+visualization was generated with the following configuration:
+\verbatim
+{
+ node = (HOST);
+ edge = (LINK);
+
+ HOST = {
+ size = power;
+ scale = global;
+
+ sep_host = {
+ type = separation;
+ size = power;
+ values = (pcompute, pfinalize);
+ };
+ };
+ LINK = {
+ src = source;
+ dst = destination;
+ size = bandwidth;
+ scale = global;
+
+ sep_link = {
+ type = separation;
+ size = bandwidth;
+ values = (bcompute, bfinalize);
+ };
+ };
+ graphviz-algorithm = neato;
+}
+\endverbatim
+<center>
+\htmlonly
+<a href="triva-graph_visualization.png" border=0><img src="triva-graph_visualization.png" width="50%" border=0></a>
+\endhtmlonly
+</center>
+
+- <b>Understading Triva - colors</b>: An important issue when using Triva is how
+ to define colors. To do that, we have to know which variables are defined in
+the trace file generated by the SimGrid library. The parameter <em>--list</em>
+lists the variables for a given trace file:
+\verbatim
+$ Triva -l masterslave_forwarder.trace
+iFile
+c platform
+c HOST
+v power
+v is_slave
+v is_master
+v task_creation
+v task_computation
+v pcompute
+v pfinalize
+c LINK
+v bandwidth
+v latency
+v bcompute
+v bfinalize
+c user_type
+\endverbatim
+We can see that HOST has seven variables (from power to pfinalize) and LINK has
+four (from bandwidth to bfinalize). To define a red color for the
+<i>pcompute</i> and <i>bcompute</i> (which are defined based on user category
+<i>compute</i>), execute:
+\verbatim
+$ defaults write Triva 'pcompute Color' '1 0 0'
+$ defaults write Triva 'bcompute Color' '1 0 0'
+\endverbatim
+Where the three numbers in each line are the RGB color with values from 0 to 1.
+
+\subsection faq_modelchecking Model-Checking
+\subsubsection faq_modelchecking_howto How to use it
+To enable the experimental SimGrid model-checking support the program should
+be executed with the command line argument
+\verbatim
+--cfg=model-check:1
+\endverbatim
+Properties are expressed as assertions using the function
+\verbatim
+void MC_assert(int prop);
+\endverbatim
+
+\subsection faq_binding_lua Lua Binding
+Most of Simgrid modules require a good level in C programming, since simgrid is used to be as standard C library.
+ Sometime users prefer using some kind of « easy scripts » or a language easier to code with, for their works,
+ which avoid dealing with C errors, and sometime an important gain of time.
+Besides Java Binding, Lua and Ruby bindings are available since version 3.4 of Simgrid
+for MSG Module, and we are currenlty working on bindings for other modules.
+
+
+\subsubsection faq_binding_lua_about What is lua ?
+Lua is a lightweight, reflective, imperative and functional programming language,
+ designed as a scripting language with extensible semantics as a primary goal (see official web site <a href="http://www.lua.org">here</a>).
+\subsubsection faq_binding_lua_why Why lua ?
+Lua is a fast, portable and powerful script language, quite simple to use for developpers.
+it combines procedural features with powerful data description facilities,
+ by using a simple, yet powerful, mechanism of tables.
+Lua has a relatively simple C API compared to other scripting languages,
+and accordingly it provides a robust, easy to use it.
+\subsubsection faq_binding_lua_simgrid How to use lua in Simgrid ?
+Actually, the use of lua in Simgrid is quite simple, you have just to follow the same steps as coding with C in Simgird :
+ - Coding functions coresponding to each process
+ - loading the platforme/deployment XML file that describe the environment of simulation
+ - and … Running the Simulation.
+
+\dontinclude lua/master_slave.lua
+\subsubsection faq_binding_lua_example_master_slave Master/Slave Example
+
+ \li Master Code
+ \until end_of_master
+we mainly use simgrid.Task.new(task_name,computation_size,communication_size) to create our MSG Task,
+ then simgrid.Task.send(task,alias) to send it.
+we use also simgrid.Task.name(task), to get the task's name.
+
+\li Slave Code
+\until end_of_slave
+Here, we see the use of simgrid.Task.recv(alias) to receive a task with a specific alias,
+this function return directly the task recevied.
+
+\li Set Environmenet and run application
+\until simgrid.clean()
+
+\subsubsection faq_binding_lua_example_data Exchanging Data
+You can also exchange data between Process using lua. for that, you have to deal with lua task as a table,
+since lua is based itself on a mechanism of tables,
+so you can exchange any kind of data (tables, matrix, strings,…) between process via tasks.
+
+\li Sender process
+\verbatim
+ task = simgrid.Task.new("data_task",task_comp,task_comm);
+ task['matrix'] = my_matrix;
+ task['table'] = my_table;
+ task['message'] = "Hello from (Lua || Simgrid ) !! "
+ …
+ simgrid.Task.send(task,alias)
+\endverbatim
+ After creating task, we associate to it various kind of data with a specific key (string in this case)
+ to distinguish between data variables. The receiver will use this key to access easily to datas.
+
+
+\li Receiver processe
+\verbatim
+ task = simgrid.Task.recv(alias);
+ sender_matrix = task['matrix'];
+ sender_table = task['table'];
+ sender_message = task['message']
+ ...
+\endverbatim
+ Note that in lua, both sender and receiver share the same lua task.
+ So that the receiver could joint data directly on the received task without sending it back.
+ You can find a complet example (matrix multiplication case) in the file example/lua/mult_matrix.lua.
+
+
+\subsubsection faq_binding_lua_example_bypass Bypass XML
+ maybe you wonder if there is a way to bypass the XML files,
+ and describe your platform directly from the code, with lua bindings it's Possible !! how ?
+ We provide some additional (tricky?) functions in lua that allows you to set up your own platform without using the XML files
+ ( this can be useful for large platforms, so a simple for loop will avoid you to deal with an annoying XML File ;) )
+
+
+\li set Routing mode
+\verbatim
+ simgrid.AS.new{id="AS0",mode="Full"};
+\endverbatim
+
+\li set Hosts
+\verbatim
+ simgrid.Host.new{id="Tremblay",power=98095000};
+ simgrid.Host.new{id="Jupiter",power=76296000};
+ simgrid.Host.new{id="Fafard",power=76296000};
+ simgrid.Host.new{id="Ginette",power=48492000};
+ simgrid.Host.new{id="Bourassa",power=48492000};
+\endverbatim
+ we use simgrid.Host.new{id=id_host,power=power_host} to instanciate our hosts.
+
+\li set Links
+\verbatim
+ for i=0,11 do
+ simgrid.Link.new{id=i,bandwidth=252750+ i*768,latency=0.000270544+i*0.087}; -- some crazy values ;)
+ end
+\endverbatim
+ we used simgrid.Link.new{id=link_id,bandwidth=bw,latency=lat} with a simple for loop to create all links we need (much easier than XML hein ?)
+
+\li set Routes
+\verbatim
+-- simgrid.Route.new(src_id,des_id,links_nb,links_list)
+ simgrid.Route.new("Tremblay","Jupiter",1,{"1"});
+ simgrid.Route.new("Tremblay","Fafard",6,{"0","1","2","3","4","8"});
+ simgrid.Route.new("Tremblay","Ginette",3,{"3","4","5"});
+ simgrid.Route.new("Tremblay","Bourassa",7,{"0","1","3","2","4","6","7"});
+
+ simgrid.Route.new("Jupiter","Tremblay",1,{"1"});
+ simgrid.Route.new("Jupiter","Fafard",7,{"0","1","2","3","4","8","9"});
+ simgrid.Route.new("Jupiter","Ginette",4,{"3","4","5","9"});
+ simgrid.Route.new("Jupiter","Bourassa",8,{"0","1","2","3","4","6","7","9"});
+ ...
+\endverbatim
+ for each host you have to specify which route to choose to access to the rest of hosts connected in the grid.
+
+\li Save platform
+\verbatim
+ simgrid.register_platform();
+\endverbatim
+Don't forget to register your platform, that SURF callbacks starts their work ;)
+
+\li set application
+\verbatim
+ simgrid.Host.setFunction("Tremblay","Master",4,{"20","550000000","1000000","4"});
+ simgrid.Host.setFunction("Bourassa","Slave",1,{"0"});
+ simgrid.Host.setFunction("Jupiter","Slave",1,{"1"});
+ simgrid.Host.setFunction("Fafard","Slave",1,{"2"});
+ simgrid.Host.setFunction("Ginette","Slave",1,{"3"});
+\endverbatim
+ you don't need to use a deployment XML file, thanks to simgrid.Host.setFunction(host_id,function,args_number,args_list)
+ you can associate functions for each host with arguments if needed .
+
+\li
+\verbatim
+ simgrid.register_application();
+\endverbatim
+Yes, Here too you have to resgiter your application before running the simulation.
+
+the full example is distributed in the file examples/lua/master_slave_bypass.lua
+
+\subsection faq_binding_ruby Ruby Binding
+
+
+\subsubsection faq_binding_ruby_simgrid Use Ruby in Simgrid
+Since v3.4, the use of <a href="http://ruby-lang.org">ruby</a> in simgrid is available for the MSG Module.
+you can find almost all MSG functionalities in Ruby code, that allows you to set up your environment, manage tasks between hosts and run the simulation.
+
+\dontinclude ruby/MasterSlave.rb
+\subsubsection faq_binding_ruby_example Master/Slave Ruby Application
+for each process method(master and slave in this example), you have to associate a ruby class, that should inherit from <i>MSG::Process</i> ruby class,
+ with a 'main' function that describe the behaviour of the process during the simulation.
+\li required stuff
+\verbatim
+require 'simgrid'
+include MSG
+\endverbatim
+
+\li Master code
+\until end_of_master
+
+the class MSG::Task contains methods that allows the management of the native MSG tasks.
+in master ruby code we used :
+ - <i>MSG::Task.new(task_name,compute_size,communication_size)</i> : to instanciate a new task.
+ - <i>MSG::Task.send(mailbox)</i> : to send the task via a mailbox alias.
+ - <i>MSG::Task.name</i> : to get the task's name.
+
+\li Slave code
+\until end_of_slave
+to receive a task, we use the method <i>MSG::Task.receive(mailbox)</i> that return a MSG:Task object (received task).
+
+\li Main chunk
+\until MSG.exit
+
+- <i>MSG.createEnvironment(platform_file)</i> : set up the environment
+- <i>MSG.deployApplication(deployment_file)</i> : load the deployment file description.
+- <i>MSG.run</i> : run the simulation
+
+\subsubsection faq_binding_ruby_data Exchanging data
+ruby bindings provides two ways to exchange data between ruby processes.
+\li MSG::Task.join & MSG::Task.data \br
+
+ the MSG::Task class contains 2 methods that allows a data exchange between 2 process.
+
+ -<i>MSG::Task.join</i> : makes possible to join any kind of ruby data within a task.
+ \verbatim
+ ...
+ myTable = Array.new
+ myTable <<1<<-2<<45<<67<<87<<76<<89<<56<<78<<3<<-4<<99
+ # Creates and send Task With the Table inside
+ task = MSG::Task.new("quicksort_task",taskComputeSize, taskCommunicationSize);
+ task.join(myTable);
+ ...
+ task.send(mailbox);
+ \endverbatim
+ -<i>MSG::Task.data</i> : to access to the data contained into the task.
+ \verbatim
+ ...
+ task = MSG::Task.receive(recv_mailbox.to_s)
+ table = task.data
+ quicksort(table,0,table.size-1)
+ ...
+ \endverbatim
+you can find a complet example illustrating the use of those methods in file /example/ruby/Quicksort.rb
+
+\li inheritence
+
+ another 'object-oriented' way to do it, is to make your own 'task' class that inherit from MSG::Task ,
+ and contains data you want to deal with, the only 'tricky' thing is that "the initializer" method has no effect !
+
+ the use of some getter/setter methods would be the simple way to manage your data :)
+ \verbatim
+class PingPongTask < MSG::Task
+ # The initialize method has no effect
+ @time
+ def setTime(t)
+ @time = t
+ end
+ def getTime()
+ return @time
+ end
+end
+ \endverbatim
+ you can find an example of use in file example/ruby/PingPong.rb