doc/module-gras.doc

   1 /** \addtogroup GRAS_API
   2
   3     \section GRAS_funct Offered functionnalities
   4      - <b>Communication facilities</b>: Exchanging messages between peers
   5        - \ref GRAS_dd: any data which may transit on the network must be
   6          described beforehand so that GRAS can handle the platform
   7          heterogeneity and convert them if needed.
   8        - \ref GRAS_sock: this is how to open a communication channel to
   9          other processes, and retrive information about them.
  10        - \ref GRAS_msg: communications are message oriented. You have to
  11          describe all possible messages and their payload beforehand, and
  12          can then attach callbacks to the arrival of a given kind of message.
  13      - <b>Virtualization</b>: Running both on top of the simulator and on
  14        top of real platforms, and portability support.
  15        - \ref GRAS_globals: The use of globals is forbidden since the
  16          "processes" are threads in simulation mode. \n
  17          This is how to let GRAS handle your globals properly.
  18        - \ref GRAS_main_generation: Since processes are threads in
  19           simulation mode and regular processes in the real world, GRAS does
  20           generate your main functions for you.
  21        - \ref GRAS_cond: How to declare specific code for the simulation mode
  22           or for the real mode.
  23        - \ref GRAS_virtu: You naturally don't want to call the
  24           gettimeofday(2) function in simulation mode since it would give
  25           you the time on the host running the simulation, not the time in
  26           the simulated world (you are belonging to).\n
  27           This a system call virtualization layer, which also acts as a
  28           portability layer.
  29
  30     \section GRAS_example Examples
  31
  32     There is for now rather few examples of GRAS, but it's better than
  33     nothing, isn't it?
  34
  35        - \ref GRAS_ex_ping
  36
  37     @{ */
  38        /** \defgroup GRAS_dd      Data description      */
  39        /** \defgroup GRAS_sock    Sockets               */
  40        /** \defgroup GRAS_msg     Messages              */
  41
  42        /** \defgroup GRAS_globals Globals               */
  43        /** \defgroup GRAS_cond    Conditional execution */
  44        /** \defgroup GRAS_virtu   Syscalls              */
  45
  46 /** @} */
  47
  48 /** \page GRAS_main_generation main() and GRAS
  49
  50     <center>[\ref GRAS_API]</center>
  51
  52     \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
  53
  54     In simulation mode, all processes are run as thread of the same process
  55     while they are real processes in the real life. Unfortunately, the main
  56     function of a real process must be called <tt>main</tt> while this
  57     function must not use this name for threads.
  58
  59     To deal with this, you should call the main function of your processes
  60     with another name (usually, the process function such as client, server,
  61     or such). Then GRAS can generate the wrapper functions adapted to the
  62     real and simulated modes.
  63
  64     \section GRAS_maingen_script Generating the main()s manually with
  65
  66     This is done by the gras_stub_generator program, which gets installed on
  67     <tt>make install</tt> (the source resides in the tools/gras/ directory).
  68     Here is the calling syntax:
  69     \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
  70
  71     It parses the deployment file, searching for all the kind of processes
  72     you have in your project. It then generates the following C files:
  73      - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
  74        have\n
  75        They are used to launch your project in real life. They
  76        contain a main() in charge of initializing the GRAS infrastructure and
  77        launching your code afterward.
  78      - a <tt>_<project_name>_simulator.c</tt> file.\n
  79        This file is suited to the simulation mode. It contains a main()
  80        function initializing the simulator and launching your project within.
  81
  82     For this to work, the name of process described in your deployment file
  83     should match the name of a function in your code, which prototype is for
  84     example: \verbatim int client(int argc,char *argv[]);\endverbatim
  85
  86     Unfortunately, all this is still partially documented. I guess I ought
  87     to improve this situation somehow. In the meanwhile, check the generated
  88     code and maybe also the GRAS \ref GRAS_example, sorry.
  89
  90     \section GRAS_maingen_make Integration within your Makefile
  91
  92     The easiest to set it up is to add the following chunk at the end of
  93     your Makefile (or Makefile.am), putting the right values into NAME and
  94     PROCESSES.
  95 \verbatim NAME=your_project_name
  96  PROCESSES=list of processes type in your project
  97
  98  $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
  99         path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
 100 \endverbatim
 101
 102     Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
 103 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml
 104         $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
 105 \endverbatim
 106
 107      */
 108
 109 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
 110
 111     <center>[\ref GRAS_API]</center>
 112
 113     This example implements the very classical ping-pong in GRAS. It
 114     involves a client (initiating the ping-pong) and a server (answering to
 115     client's requests).
 116
 117     It works the following way:
 118      - Both the client and the server register all needed messages
 119      - The server registers a callback to the ping message, which sends pong
 120        to the expeditor
 121      - The client sends the ping message to the server, and waits for the
 122        pong message as an answer.
 123
 124     This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
 125     the code of the client and of the server is placed in the same file. See
 126     the \ref GRAS_main_generation section if wondering.
 127
 128     \section GRAS_ex_ping_over Overview
 129       - \ref GRAS_ex_ping_common
 130         - \ref GRAS_ex_ping_initial
 131         - \ref GRAS_ex_ping_register
 132       - \ref GRAS_ex_ping_server
 133         - \ref GRAS_ex_ping_serdata
 134         - \ref GRAS_ex_ping_sercb
 135         - \ref GRAS_ex_ping_sermain
 136       - \ref GRAS_ex_ping_client
 137         - \ref GRAS_ex_ping_climain
 138
 139     <hr>
 140
 141     \dontinclude gras/ping/ping.c
 142
 143     \section GRAS_ex_ping_common 1) Common code to the client and the server
 144
 145     \subsection GRAS_ex_ping_initial 1.a) Initial settings
 146
 147     Let's first load the gras header and declare a logging category (see
 148     \ref XBT_log for more info on logging).
 149
 150     \skip include
 151     \until XBT_LOG
 152
 153     \subsection GRAS_ex_ping_register 1.b) Register the messages
 154
 155     This function, called by both the client and the server is in charge of
 156     declaring the existing messages to GRAS. Since the payload does not
 157     involve any newly created types but only int, this is quite easy.
 158     (to exchange more complicated types, see \ref GRAS_dd)
 159
 160     \skip register_messages
 161     \until }
 162
 163     \section GRAS_ex_ping_server 2) Server's code
 164
 165     \subsection GRAS_ex_ping_serdata 2.a) The server's globals
 166
 167     In order to ensure the communication between the "main" and the callback
 168     of the server, we need to declare some globals. We have to put them in a
 169     struct definition so that they can be handled properly in GRAS (see the
 170     \ref GRAS_globals for more info).
 171
 172     \skip typedef struct
 173     \until }
 174
 175     \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
 176
 177     Here is the callback run when the server receives any ping message (this
 178     will be registered later by the server).
 179
 180     \skip server_cb_ping_handler
 181     \until end_of_server_cb_ping_handler
 182
 183     \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
 184
 185     This is the "main" of the server. As explained in the \ref
 186     GRAS_main_generation, you don't have to (and shouldn't) write any main()
 187     function yourself. Instead, you just have to write a regular function
 188     like this one which will act as a main.
 189
 190     \skip server
 191     \until end_of_server
 192
 193     \section GRAS_ex_ping_client 3) Client's code
 194
 195     \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
 196
 197     \skip client
 198     \until end_of_client
 199
 200
 201   */
 202