1 /** \addtogroup GRAS_API
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 - \ref GRAS_timer: this is how to program repetitive and delayed
14 tasks, not unlike cron(8) and at(1). This cannot be used to timeout
15 a function (like setitimer(2) or signal(2) games could do).
16 - <b>Virtualization</b>: Running both on top of the simulator and on
17 top of real platforms, and portability support.
18 - \ref GRAS_globals: The use of globals is forbidden since the
19 "processes" are threads in simulation mode. \n
20 This is how to let GRAS handle your globals properly.
21 - \ref GRAS_main_generation: Since processes are threads in
22 simulation mode and regular processes in the real world, GRAS does
23 generate your main functions for you.
24 - \ref GRAS_cond: How to declare specific code for the simulation mode
26 - \ref GRAS_virtu: You naturally don't want to call the
27 gettimeofday(2) function in simulation mode since it would give
28 you the time on the host running the simulation, not the time in
29 the simulated world (you are belonging to).\n
30 This a system call virtualization layer, which also acts as a
33 \section GRAS_example Examples
35 There is for now rather few examples of GRAS, but it's better than
42 /** \defgroup GRAS_dd Data description */
43 /** \defgroup GRAS_sock Sockets */
44 /** \defgroup GRAS_msg Messages */
45 /** \defgroup GRAS_timer Timers */
47 /** \defgroup GRAS_globals Globals */
48 /** \defgroup GRAS_cond Conditional execution */
49 /** \defgroup GRAS_virtu Syscalls */
53 /** \page GRAS_main_generation main() and GRAS
55 <center>[\ref GRAS_API]</center>
57 \section GRAS_maingen_intro What's the matter with main() functions in GRAS?
59 In simulation mode, all processes are run as thread of the same process
60 while they are real processes in the real life. Unfortunately, the main
61 function of a real process must be called <tt>main</tt> while this
62 function must not use this name for threads.
64 To deal with this, you should call the main function of your processes
65 with another name (usually, the process function such as client, server,
66 or such). Then GRAS can generate the wrapper functions adapted to the
67 real and simulated modes.
69 \section GRAS_maingen_script Generating the main()s manually with
71 This is done by the gras_stub_generator program, which gets installed on
72 <tt>make install</tt> (the source resides in the tools/gras/ directory).
73 Here is the calling syntax:
74 \verbatim gras_stub_generator <project_name> <deployment_file.xml>\endverbatim
76 It parses the deployment file, searching for all the kind of processes
77 you have in your project. It then generates the following C files:
78 - a <tt>_<project_name>_<process_kind>.c</tt> file for each process kind you
80 They are used to launch your project in real life. They
81 contain a main() in charge of initializing the GRAS infrastructure and
82 launching your code afterward.
83 - a <tt>_<project_name>_simulator.c</tt> file.\n
84 This file is suited to the simulation mode. It contains a main()
85 function initializing the simulator and launching your project within.
87 For this to work, the name of process described in your deployment file
88 should match the name of a function in your code, which prototype is for
89 example: \verbatim int client(int argc,char *argv[]);\endverbatim
91 Unfortunately, all this is still partially documented. I guess I ought
92 to improve this situation somehow. In the meanwhile, check the generated
93 code and maybe also the GRAS \ref GRAS_example, sorry.
95 \section GRAS_maingen_make Integration within your Makefile
97 The easiest to set it up is to add the following chunk at the end of
98 your Makefile (or Makefile.am), putting the right values into NAME and
100 \verbatim NAME=your_project_name
101 PROCESSES=list of processes type in your project
103 $(foreach proc, $(PROCESSES), _$(NAME)_$(proc).c) _$(NAME)_simulator.c: $(NAME).c $(NAME)_deployment.xml
104 path/to/gras_stub_generator $(NAME) $(NAME)_deployment.xml >/dev/null
107 Of course, your personal millage may vary. For the \ref GRAS_ex_ping, may read:
108 \verbatim _ping_client.c _ping_server.c _ping_simulator.c: ping.c ping_deployment.xml
109 $(top_srcdir)/tools/gras/gras_stub_generator ping ping_deployment.xml >/dev/null
114 /** \page GRAS_ex_ping The classical Ping-Pong in GRAS
116 <center>[\ref GRAS_API]</center>
118 This example implements the very classical ping-pong in GRAS. It
119 involves a client (initiating the ping-pong) and a server (answering to
122 It works the following way:
123 - Both the client and the server register all needed messages
124 - The server registers a callback to the ping message, which sends pong
126 - The client sends the ping message to the server, and waits for the
127 pong message as an answer.
129 This example resides in the <b>examples/gras/ping/ping.c</b> file. Yes, both
130 the code of the client and of the server is placed in the same file. See
131 the \ref GRAS_main_generation section if wondering.
133 \section GRAS_ex_ping_over Overview
134 - \ref GRAS_ex_ping_common
135 - \ref GRAS_ex_ping_initial
136 - \ref GRAS_ex_ping_register
137 - \ref GRAS_ex_ping_server
138 - \ref GRAS_ex_ping_serdata
139 - \ref GRAS_ex_ping_sercb
140 - \ref GRAS_ex_ping_sermain
141 - \ref GRAS_ex_ping_client
142 - \ref GRAS_ex_ping_climain
146 \dontinclude gras/ping/ping.c
148 \section GRAS_ex_ping_common 1) Common code to the client and the server
150 \subsection GRAS_ex_ping_initial 1.a) Initial settings
152 Let's first load the gras header and declare a logging category (see
153 \ref XBT_log for more info on logging).
158 \subsection GRAS_ex_ping_register 1.b) Register the messages
160 This function, called by both the client and the server is in charge of
161 declaring the existing messages to GRAS. Since the payload does not
162 involve any newly created types but only int, this is quite easy.
163 (to exchange more complicated types, see \ref GRAS_dd)
165 \skip register_messages
168 \section GRAS_ex_ping_server 2) Server's code
170 \subsection GRAS_ex_ping_serdata 2.a) The server's globals
172 In order to ensure the communication between the "main" and the callback
173 of the server, we need to declare some globals. We have to put them in a
174 struct definition so that they can be handled properly in GRAS (see the
175 \ref GRAS_globals for more info).
180 \subsection GRAS_ex_ping_sercb 2.b) The callback to the ping message
182 Here is the callback run when the server receives any ping message (this
183 will be registered later by the server).
185 \skip server_cb_ping_handler
186 \until end_of_server_cb_ping_handler
188 \subsection GRAS_ex_ping_sermain 2.c) The "main" of the server
190 This is the "main" of the server. As explained in the \ref
191 GRAS_main_generation, you don't have to (and shouldn't) write any main()
192 function yourself. Instead, you just have to write a regular function
193 like this one which will act as a main.
198 \section GRAS_ex_ping_client 3) Client's code
200 \subsection GRAS_ex_ping_climain 3.a) Client's "main" function
206 /** \page GRAS_ex_timer Some timer games
208 <center>[\ref GRAS_API]</center>
210 This example fools around with the GRAS timers (\ref GRAS_timer). It is
211 mainly a regression test, since it uses almost all timer features.
213 The main program registers a repetititive task and a delayed one, and
214 then loops until the <tt>still_to_do</tt> variables of its globals reach
215 0. The delayed task set it to 5, and the repetititive one decrease it
216 each time. Here is an example of output:
217 \verbatim Initialize GRAS
219 [1108335471] Programming the repetitive_action with a frequency of 1.000000 sec
220 [1108335471] Programming the delayed_action for after 2.000000 sec
221 [1108335471] Have a rest
222 [1108335472] Canceling the delayed_action.
223 [1108335472] Re-programming the delayed_action for after 2.000000 sec
224 [1108335472] Repetitive_action has nothing to do yet
225 [1108335473] Repetitive_action has nothing to do yet
226 [1108335473] delayed_action setting globals->still_to_do to 5
227 [1108335474] repetitive_action decrementing globals->still_to_do. New value: 4
228 [1108335475] repetitive_action decrementing globals->still_to_do. New value: 3
229 [1108335476] repetitive_action decrementing globals->still_to_do. New value: 2
230 [1108335477] repetitive_action decrementing globals->still_to_do. New value: 1
231 [1108335478] repetitive_action decrementing globals->still_to_do. New value: 0
232 Exiting GRAS\endverbatim
235 - \ref GRAS_ex_timer_decl
236 - \ref GRAS_ex_timer_delay
237 - \ref GRAS_ex_timer_repeat
238 - \ref GRAS_ex_timer_main
242 \section GRAS_ex_timer_decl 1. Declarations and headers
246 \section GRAS_ex_timer_delay 2. Source code of the delayed action
247 \skip repetitive_action
248 \until end_of_repetitive_action
250 \section GRAS_ex_timer_repeat 3. Source code of the repetitive action
252 \until end_of_delayed_action
254 \section GRAS_ex_timer_main 4. Source code of main function