are done sequentially by this thread. The model is thus <b>1-port in
reception</b>, but something like 2-port in general. Moreover, the messages not
matching the criterion in explicite receive (see for example \ref
-gras_msg_wait) are queued for further use.
+gras_msg_wait) are queued for further use. Thanks to this specific
+thread, the emission and reception are completely decorelated. Ie, the
+main thread can perfectly send a message while the listener is
+receiving something. We thus have a classical <b>1-port model</b>.
Here is a graphical representation of a scenario involving two processes A and
B. Both are naturally composed of two threads: the one running user code, and
(2) is mainly given by the network bandwidth. This is the time for all bytes of
the messages to travel from one machine to the other. Please note that the
models used by SimGrid are a bit more complicated to keep realistic, as
-explained in <a href="http://www.loria.fr/~quinson/articles/simgrid-tutorial.pdf">the
-tutorial slides</a>, but this not that important here. The time (3) is mainly
+explained in <a href="http://www.loria.fr/~quinson/blog/2010/06/28/Tutorial_at_HPCS/">the
+slides of the HPCS'10</a>, but this not that important here. The time (3) is mainly
found in the SG version and not in RL (and that's a bug). This is the time to
make sure that message were received on machine B. In real life, some buffering
at system and network level may give the illusion to machine A that the message