docs/source/platform_examples.rst

   1 .. raw:: html
   2
   3    <object id="TOC" data="graphical-toc.svg" width="100%" type="image/svg+xml"></object>
   4    <script>
   5    window.onload=function() { // Wait for the SVG to be loaded before changing it
   6      var elem=document.querySelector("#TOC").contentDocument.getElementById("PlatformBox")
   7      elem.style="opacity:0.93999999;fill:#ff0000;fill-opacity:0.1;stroke:#000000;stroke-width:0.35277778;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1";
   8    }
   9    </script>
  10    <br/>
  11    <br/>
  12
  13 .. _platform_examples:
  14
  15 Platform Examples
  16 =================
  17
  18 Here is a very simple platform file, containing 3 resources (two hosts
  19 and one link), and explicitly giving the route between the hosts.
  20
  21 .. literalinclude:: ../../examples/platforms/two_hosts.xml
  22    :language: xml
  23
  24 The root tag must be ``<platform>``, and its ``version`` attribute
  25 specifies which version of the DTD is use. When an evolution of the DTD introduces
  26 backward-incompatible changes, this number gets updated. Use the
  27 ``simgrid_update_xml`` utility to upgrade your platform files on need.
  28
  29 Then, every platform element must be located within a given
  30 **networking zone** introduced with the :ref:`pf_tag_zone` tag.  Zones
  31 are in charge of the routing. If a host wants to communicate with
  32 another host belonging to the same zone, it is the zone's duty to find the list
  33 of links that are involved in the communication. Here, since we use
  34 ``routing="Full"``, all routes must be explicitly given using the
  35 :ref:`pf_tag_route` and :ref:`pf_tag_linkctn` tags (this :ref:`routing
  36 model <pf_rm>` is both simple and inefficient :) It is OK to not
  37 specify each and every route between hosts, as long as you do not try to start
  38 a communication on any of the missing routes during your simulation.
  39
  40 Any zone may contain sub-zones, allowing for a hierarchical
  41 decomposition of the platform. Routing can be made more efficient (as the
  42 inter-zone routing gets factored with :ref:`pf_tag_zoneroute`), and
  43 allows you to have more than one routing model in your platform. For
  44 example, you can have a coordinate-based routing for the WAN parts
  45 of your platforms, a full routing within each datacenter, and a highly
  46 optimized routing within each cluster of the datacenter.  In this
  47 case, determining the route between two given hosts gets :ref:`routing_basics`
  48 "somewhat more complex" but SimGrid still computes
  49 these routes for you in a time- and space-efficient manner.
  50 Here is an illustration of these concepts:
  51
  52 .. image:: img/zone_hierarchy.png
  53
  54 The zone "AS2" models the core of a national network interconnecting a
  55 small flat cluster (AS4) and a larger hierarchical cluster (AS5), a
  56 subset of a LAN (AS6), and a set of peers scattered around the world
  57 (AS7).
  58
  59 .. todo:: Add more examples, such as the cloud example described in
  60           previous paragraph
  61