etc.
-\subsubsection pf_peer \<peer\> (Vivaldi netzones only)
+\subsubsection pf_peer <peer> (Vivaldi netzones only)
This tag represents a peer, as in Peer-to-Peer (P2P) networks. This
can only be used in Vivaldi NetZones. It creates the following
\subsubsection pf_router <router/>
As said before, <b>router</b> is used only to give some information
-for routing algorithms. So, it does not have any attributes except :
+for routing algorithms. So, it does not have any attributes except:
#### Attributes ####
\verbinclude example_filelist_routing_dijkstra
-Dijkstra example :
+Dijkstra example:
\verbatim
<zone id="zone_2" routing="Dijkstra">
<host id="zone_2_host1" speed="1000000000"/>
\anchor pf_routing_model_full
### Full ###
-Full example :
+Full example:
\verbatim
<zone id="zone0" routing="Full">
<host id="host1" speed="1000000000"/>
<b>bypasszoneroute</b> is the tag you're looking for. It allows to
bypass routes defined between already defined between zone (if you want
to bypass route for a specific host, you should just use byPassRoute).
-The principle is the same as zoneroute : <b>bypasszoneroute</b> contains
+The principle is the same as zoneroute: <b>bypasszoneroute</b> contains
list of links that are in the path between src and dst.
#### Attributes ####
As said before, once you choose
a model, it (most likely; the constant network model, for example, doesn't) calculates routes for you. But maybe you want to
define some of your routes, which will be specific. You may also want
-to bypass some routes defined in lower level zone at an upper stage :
+to bypass some routes defined in lower level zone at an upper stage:
<b>bypassRoute</b> is the tag you're looking for. It allows to bypass
routes defined between <b>host/router</b>. The principle is the same
-as route : <b>bypassRoute</b> contains list of links references of
+as route: <b>bypassRoute</b> contains list of links references of
links that are in the path between src and dst.
#### Attributes ####
defined inside zone_Big. If you choose some shortest-path model,
this route will be computed automatically.
-As said before, there are mainly 2 tags for routing :
+As said before, there are mainly 2 tags for routing:
\li <b>zoneroute</b>: to define routes between two <b>zone</b>
\li <b>route</b>: to define routes between two <b>host/router</b>
routing (as we don't want to bother with defining all routes). As
we're using some shortest path algorithms to route into zone_2, we'll
then have to define some <b>route</b> to gives some topological
-information to SimGrid. Here is a file doing it all :
+information to SimGrid. Here is a file doing it all:
\verbatim
<zone id="zone_Big" routing="Dijkstra">
\subsection pf_exit_zone Exit Zone: why and how
Users that have looked at some of our platforms may have notice a
-non-intuitive schema ... Something like that :
+non-intuitive schema ... Something like that:
\verbatim
Choosing wisely the routing model to use can significantly fasten your
simulation/save your time when writing the platform/save tremendous
disk space. Here is the list of available model and their
-characteristics (lookup : time to resolve a route):
+characteristics (lookup: time to resolve a route):
\li <b>Full</b>: Full routing data (fast, large memory requirements,
fully expressive)
