--- /dev/null
+# Path to the pip requirements file
+requirements_file: docs/requirements.txt
+
+# Don't build any extra formats
+formats: []
\ No newline at end of file
# generate an XML file that captures the structure of
# the code including all documentation.
-GENERATE_XML = NO
+GENERATE_XML = YES
#---------------------------------------------------------------------------
# configuration options for the AutoGen Definitions output
--- /dev/null
+# -*- coding: utf-8 -*-
+#
+# Configuration file for the Sphinx documentation builder.
+#
+# This file does only contain a selection of the most common options. For a
+# full list see the documentation:
+# http://www.sphinx-doc.org/en/master/config
+
+# -- Path setup --------------------------------------------------------------
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#
+# import os
+# import sys
+# sys.path.insert(0, os.path.abspath('.'))
+
+
+# -- Project information -----------------------------------------------------
+
+project = u'SimGrid'
+copyright = u'2018, The SimGrid Team'
+author = u'The SimGrid Team'
+
+# The short X.Y version
+version = u'3.21'
+# The full version, including alpha/beta/rc tags
+release = u'3.21'
+
+
+# -- General configuration ---------------------------------------------------
+
+# If your documentation needs a minimal Sphinx version, state it here.
+#
+# needs_sphinx = '1.0'
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = [
+# 'sphinx.ext.coverage',
+ 'sphinx.ext.mathjax',
+# 'sphinx.ext.ifconfig',
+ 'breathe',
+]
+
+breathe_projects = { 'simgrid': '../doc/xml' }
+breathe_default_project = "simgrid"
+
+# highlight_language = 'c++'
+# todo_include_todos = False
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# The suffix(es) of source filenames.
+# You can specify multiple suffix as a list of string:
+#
+# source_suffix = ['.rst', '.md']
+source_suffix = '.rst'
+
+# The master toctree document.
+master_doc = 'index'
+
+# The language for content autogenerated by Sphinx. Refer to documentation
+# for a list of supported languages.
+#
+# This is also used if you do content translation via gettext catalogs.
+# Usually you set "language" from the command line for these cases.
+language = None
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This pattern also affects html_static_path and html_extra_path .
+exclude_patterns = []
+
+# The name of the Pygments (syntax highlighting) style to use.
+pygments_style = 'sphinx'
+
+
+# -- Options for HTML output -------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+#
+html_theme = 'sphinx_rtd_theme'
+
+# Theme options are theme-specific and customize the look and feel of a theme
+# further. For a list of options available for each theme, see the
+# documentation.
+#
+# html_theme_options = {}
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+html_static_path = ['_static']
+
+# Custom sidebar templates, must be a dictionary that maps document names
+# to template names.
+#
+# The default sidebars (for documents that don't match any pattern) are
+# defined by theme itself. Builtin themes are using these templates by
+# default: ``['localtoc.html', 'relations.html', 'sourcelink.html',
+# 'searchbox.html']``.
+#
+# html_sidebars = {'**': ['localtoc.html', 'relations.html', 'searchbox.html']}
+
+# -- Options for GitLab integration ------------------------------------------
+
+html_context = {
+ "display_gitlab": True, # Integrate Gitlab
+ "gitlab_host": "framagit.org",
+ "gitlab_user": "simgrid",
+ "gitlab_repo": "simgrid",
+ "gitlab_version": "master", # Version
+ "conf_py_path": "/docs/source/", # Path in the checkout to the docs root
+}
+
+# -- Options for HTMLHelp output ---------------------------------------------
+
+# Output file base name for HTML help builder.
+htmlhelp_basename = 'SimGrid-doc'
+
+
+# -- Options for LaTeX output ------------------------------------------------
+
+latex_elements = {
+ # The paper size ('letterpaper' or 'a4paper').
+ #
+ # 'papersize': 'letterpaper',
+
+ # The font size ('10pt', '11pt' or '12pt').
+ #
+ # 'pointsize': '10pt',
+
+ # Additional stuff for the LaTeX preamble.
+ #
+ # 'preamble': '',
+
+ # Latex figure (float) alignment
+ #
+ # 'figure_align': 'htbp',
+}
+
+# Grouping the document tree into LaTeX files. List of tuples
+# (source start file, target name, title,
+# author, documentclass [howto, manual, or own class]).
+latex_documents = [
+ (master_doc, 'SimGrid.tex', u'SimGrid Documentation',
+ u'The SimGrid Team', 'manual'),
+]
+
+
+# -- Options for manual page output ------------------------------------------
+
+# One entry per manual page. List of tuples
+# (source start file, name, description, authors, manual section).
+man_pages = [
+ (master_doc, 'simgrid', u'SimGrid Documentation',
+ [author], 1)
+]
+
+
+# -- Options for Texinfo output ----------------------------------------------
+
+# Grouping the document tree into Texinfo files. List of tuples
+# (source start file, target name, title, author,
+# dir menu entry, description, category)
+texinfo_documents = [
+ (master_doc, 'SimGrid', u'SimGrid Documentation',
+ author, 'SimGrid', 'One line description of project.',
+ 'Miscellaneous'),
+]
+
+
+# -- Extension configuration -------------------------------------------------
\ No newline at end of file
--- /dev/null
+.. SimGrid documentation master file
+
+Welcome to SimGrid's documentation!
+===================================
+
+.. toctree::
+ :maxdepth: 2
+ :caption: Contents:
+
+ What is SimGrid <main_concepts.rst>
+ Installing SimGrid <installation.rst>
+ Start your Own Project <install_yours.rst>
+
+
+Indices and tables
+==================
+
+* :ref:`genindex`
+* :ref:`search`
--- /dev/null
+..
+
+Start your Own Project
+======================
+
+It is not advised to modify the simgrid source code directly, as it
+will make it difficult to upgrade to the next version of SimGrid.
+Instead, you should create your own working directory somewhere on
+your disk (say `/home/joe/MyFirstScheduler/`), and write your code in
+there.
+
+Building your project with CMake
+--------------------------------
+
+Here is a `CMakeLists.txt` that you can use as a starting point for
+your project. It builds two simulators from a given set of source files.
+
+.. code-block:: cmake
+
+ project(MyFirstScheduler)
+
+ set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -std=c++11")
+
+ set(CMAKE_MODULE_PATH ${CMAKE_MODULE_PATH} "${CMAKE_SOURCE_DIR}/cmake/Modules/")
+ find_package(SimGrid REQUIRED)
+ include_directories(${SimGrid_INCLUDE_DIR})
+
+ set(SIMULATOR_SOURCES main.c other.c util.c)
+ add_executable(my_simulator ${SIMULATOR_SOURCES})
+ target_link_libraries(my_simulator ${SimGrid_LIBRARY})
+
+ set(OTHER_SOURCES blah.c bar.c foo.h)
+ add_executable(other_xp ${OTHER_SOURCES})
+ target_link_libraries(other_xp ${SimGrid_LIBRARY})
+
+
+For that, you need <a href="https://github.com/simgrid/simgrid/blob/master/FindSimGrid.cmake">FindSimGrid.cmake</a>,
+that is located at the root of the SimGrid tree. You can either copy
+this file into the `cmake/Modules` directory of your project, or use
+the version installed on the disk. Both solutions present advantages
+and drawback: if you copy the file, you have to keep it in sync
+manually but your project will produce relevant error messages when
+trying to compile on a machine where SimGrid is not installed. Please
+also refer to the file header for more information.
+
+Building your project with Makefile
+-----------------------------------
+
+Here is a Makefile that will work if your project is composed of three
+C files named ``util.h``, ``util.c`` and ``mysimulator.c``. You should
+take it as a starting point, and adapt it to your code. There is a
+plenty of documentation and tutorial on Makefile if the file's
+comments are not enough for you.
+
+.. code-block:: makefile
+
+ # The first rule of a Makefile is the default target. It will be built when make is called with no parameter
+ # Here, we want to build the binary 'mysimulator'
+ all: mysimulator
+
+ # This second rule lists the dependencies of the mysimulator binary
+ # How this dependencies are linked is described in an implicit rule below
+ mysimulator: mysimulator.o util.o
+
+ # These third give the dependencies of the each source file
+ mysimulator.o: mysimulator.c util.h # list every .h that you use
+ util.o: util.c util.h
+
+ # Some configuration
+ SIMGRID_INSTALL_PATH = /opt/simgrid # Where you installed simgrid
+ CC = gcc # Your compiler
+ WARNING = -Wshadow -Wcast-align -Waggregate-return -Wmissing-prototypes \
+ -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes \
+ -Wmissing-declarations -Wmissing-noreturn -Wredundant-decls \
+ -Wnested-externs -Wpointer-arith -Wwrite-strings -finline-functions
+
+ # CFLAGS = -g -O0 $(WARNINGS) # Use this line to make debugging easier
+ CFLAGS = -g -O2 $(WARNINGS) # Use this line to get better performance
+
+ # No change should be mandated past that line
+ #############################################
+ # The following are implicit rules, used by default to actually build
+ # the targets for which you listed the dependencies above.
+
+ # The blanks before the $(CC) must be a Tab char, not spaces
+ %: %.o
+ $(CC) -L$(SIMGRID_INSTALL_PATH)/lib/ $(CFLAGS) $^ -lsimgrid -o $@
+ %.o: %.c
+ $(CC) -I$(SIMGRID_INSTALL_PATH)/include $(CFLAGS) -c -o $@ $<
+
+ clean:
+ rm -f *.o *~
+ .PHONY: clean
+
+Develop in C++ with Eclipse
+----------------------------------------
+
+If you wish to develop your plugin or modify SimGrid using
+Eclipse. You have to run cmake and import it as a Makefile project.
+
+Next you have to activate C++11 in your build settings, add -std=c++11
+in the CDT GCC Built-in compiler settings.
+
+.. image:: images/eclipseScreenShot.png
+
+
+Building the Java examples in Eclipse
+-------------------------------------
+
+If you want to build our Java examples in Eclipse, get the whole
+source code and open the archive on your disk. In Eclipse, select
+the menu "File / Import", and then in the wizard "General / Existing
+Project into Workspace". On the Next page, select the directory
+"examples/java" that you can find in the SimGrid source tree as a root
+directory and finish the creation.
+
+The file ``simgrid.jar`` must be in the root directory of the SimGrid
+tree. That's where it is built by default, but if you don't want to
+compile it yourself, just grab that file from the SimGrid website and
+copy it in here.
+
+Please note that once you better understand SimGrid, you should not
+modify the examples directly but instead create your own project in
+eclipse. This will make it easier to upgrade to another version of
+SimGrid.
+
+Troubleshooting your project setup
+----------------------------------
+
+Library not found
+^^^^^^^^^^^^^^^^^
+
+When the library cannot be found, you will get such an error message similar:
+
+.. code-block:: shell
+
+ ./masterworker1: error while loading shared libraries: libsimgrid.so: cannot open shared object file: No such file or directory
+
+To fix this, give the path to where you installed the library into the
+``LD_LIBRARY_PATH`` variable. You can add the following line to your
+``~/.bashrc`` so that it gets executed each time you log into your
+computer.
+
+.. code-block:: shell
+
+ export LD_LIBRARY_PATH=/opt/simgrid/lib
+
+
+Many undefined references
+^^^^^^^^^^^^^^^^^^^^^^^^^
+
+.. code-block:: shell
+
+ masterworker.c:209: undefined reference to `sg_version_check'
+ masterworker.c:209: undefined reference to `MSG_init_nocheck'
+ (and many other undefined references)
+
+This happens when the linker tries to use the wrong library. Use
+``LD_LIBRARY_PATH`` as in the previous item to provide the path to the
+right library.
+
+Only a few undefined references
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Sometimes, the compilation only spits very few "undefined reference"
+errors. A possible cause is that the system selected an old version of
+the SimGrid library somewhere on your disk.
+
+Dicover which version is used with ``ldd name-of-yoursimulator``.
+Once you've found the obsolete copy of SimGrid, just erase it, and
+recompile and relaunch your program.
--- /dev/null
+.. Copyright 2005-2018
+
+Installing SimGrid
+==================
+
+
+SimGrid should work out of the box on Linux, Mac OSX, FreeBSD, and Windows (under windows, only the Java interfaces are
+available at the moment).
+
+Pre-compiled Packages
+---------------------
+
+Binaries for Linux
+^^^^^^^^^^^^^^^^^^
+
+On Debian or Ubuntu, simply type:
+
+.. code-block:: shell
+
+ apt install simgrid
+
+If you build pre-compiled packages for other distributions, drop us an
+email.
+
+Stable Java Package
+^^^^^^^^^^^^^^^^^^^
+
+The jar file can be retrieved from the `Release page
+<https://framagit.org/simgrid/simgrid/tags>`_. This file is
+self-contained, including the native components for Linux, Mac OSX and
+Windows. Copy it to your project's classpath and you're set.
+
+Nightly built Java Package
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+For non-Windows systems (Linux, Mac or FreeBSD), head to `Jenkins <https://ci.inria.fr/simgrid/job/SimGrid>`_.
+In the build history, pick the last green (or at least yellow) build that is not blinking (i.e., not currently under
+build). In the list, pick a system that is close to yours, and click on the ball in the Debug row. The build artefact
+will appear on the top of the resulting page.
+
+For Windows, head to `AppVeyor <https://ci.appveyor.com/project/simgrid/simgrid>`_.
+Click on the artefact link on the right, and grab your file. If the latest build failed, there will be no artefact. Then
+you will need to first click on "History" on the top and search for the last successful build.
+
+Binary Java Troubleshooting
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Here are some error messages that you may get when trying to use the
+binary Java package.
+
+Your architecture is not supported by this jarfile
+ If your system is not supported, you should compile your
+ own jarfile :ref:`by compiling SimGrid <install_src>` from the source.
+Library not found: boost-context
+ You should obviously install the ``boost-context`` library on your
+ machine, for example with ``apt``.
+
+.. _install_src:
+
+Installing from the Source
+--------------------------
+
+Getting the Dependencies
+^^^^^^^^^^^^^^^^^^^^^^^^
+
+C++ compiler (either g++, clang or icc).
+ We use the C++11 standard, and older compilers tend to fail on
+ us. It seems that g++ 5.0 or higher is required nowadays (because of
+ boost). SimGrid compiles well with `clang` or `icc` too.
+Python 3.
+ SimGrid should build without Python, that is only needed by our regresion test suite.
+cmake (v2.8.8).
+ ``ccmake`` provides a nicer graphical interface compared to ``cmake``.
+ Press ``t`` in ``ccmake`` if you need to see absolutely all
+ configuration options (e.g., if your python installation is not standard).
+boost (at least v1.48, v1.59 recommended)
+ - On Debian / Ubuntu: ``apt install libboost-dev libboost-context-dev``
+ - On Max OS X with homebrew: ``brew install boost``
+Java (optional):
+ - Debian / Ubuntu: ``apt install default-jdk libgcj18-dev`` (or
+ any version of libgcj)
+ - Mac OS X or Windows: Grab a `full JDK <http://www.oracle.com/technetwork/java/javase/downloads>`_
+Lua (optional -- must be v5.3)
+ - SimGrid won't work with any other version of Lua.
+ - Debian / Ubuntu: ``apt install liblua5.3-dev lua5.3``
+ - Windows: ``choco install lua53``
+ - From the source
+ - You need to patch the sources to build dynamic libraries. First `download lua 5.3 <http://www.lua.org/download.html>`_
+ - Open the archive: ``tar xvfz lua-5.3.*.tar.gz``
+ - Enter the directory: ``cd lua-5.3*``
+ - Patch the sources: ``patch -p1 < /path/to/simgrid/...../tools/lualib.patch``
+ - Build and install lua: ``make linux && sudo make install``
+
+For platform-specific details, please see below.
+
+Getting the Sources
+^^^^^^^^^^^^^^^^^^^
+
+Grab the last **stable release** from `FramaGit
+<https://framagit.org/simgrid/simgrid/tags>`_, and compile it as follows:
+
+.. code-block:: shell
+
+ tar xf SimGrid-3-XX.tar.gz
+ cd SimGrid-*
+ cmake -DCMAKE_INSTALL_PREFIX=/opt/simgrid .
+ make
+ make install
+
+If you want to stay on the **bleeding edge**, get the current git version,
+and recompile it as with stable archives. You may need some extra
+dependencies.
+
+.. code-block:: shell
+
+ git clone git@framagit.org:simgrid/simgrid.git
+ cd simgrid
+ cmake -DCMAKE_INSTALL_PREFIX=/opt/simgrid .
+ make
+ make install
+
+Build Configuration
+^^^^^^^^^^^^^^^^^^^
+
+This section is about **compile-time options**, that are very
+different from @ref options "run-time options". Compile-time options
+fall into two categories. *SimGrid-specific options* define which part
+of the framework to compile while *Generic options* are provided by
+cmake itself.
+
+Generic build-time options
+""""""""""""""""""""""""""
+
+These options specify for example the path to various system elements
+(Python path, compiler to use, etc). In most case, cmake automatically
+discovers the right value for these ones, but you can set them
+manually on need. Notable such variables include ``CC`` and ``CXX``,
+defining respectively the paths to the C and C++ compilers, ``CFLAGS``
+and ``CXXFLAGS`` respectively specifying extra options to pass to the C
+and C++ compilers, or ``PYTHON_EXECUTABLE`` specifying the path to the
+python executable.
+
+The best way to discover the exact name of the option that you need to
+change is to press ``t`` in the ``ccmake`` graphical interface, as all
+options are shown (and documented) in the advanced mode.
+
+Once you know their name, there is several ways to change the value of
+build-time options. You can naturally use the ccmake graphical
+interface for that, or you can use environment variables, or you can
+prefer the ``-D`` flag of ``cmake``.
+
+For example, you can change the compilers with environment variables
+by issuing these commands before launching cmake:
+
+.. code-block:: shell
+
+ export CC=gcc-5.1
+ export CXX=g++-5.1
+
+The same can be done by passing ``-D`` parameters to cmake, as follows.
+Note that the ending dot is mandatory (see :ref:`install_cmake_outsrc`).
+
+.. code-block:: shell
+
+ cmake -DCC=clang -DCXX=clang++ .
+
+SimGrid compilation options
+"""""""""""""""""""""""""""
+
+Here is the list of all SimGrid-specific build-time options (the
+default choice is in uppercase).
+
+CMAKE_INSTALL_PREFIX (path)
+ Where to install SimGrid (/opt/simgrid, /usr/local, or elsewhere).
+
+enable_compile_optimizations (ON/off)
+ Request the compiler to produce efficient code. You probably want to
+ activate this option, unless you plan modify SimGrid itself:
+ efficient code takes more time to compile, and appears mangled to debuggers.
+
+enable_compile_warnings (on/OFF)
+ Request the compiler to issue error messages whenever the source
+ code is not perfectly clean. If you are a SimGrid developer, you
+ have to activate this option to enforce the code quality. As a
+ regular user, this option is of little use.
+
+enable_debug (ON/off)
+ Disabling this option toto discards all log messages of gravity
+ debug or below at compile time (see @ref XBT_log). The resulting
+ code is faster than if you discarding these messages at
+ runtime. However, it obviously becomes impossible to get any debug
+ info from SimGrid if something goes wrong.
+
+enable_documentation (ON/off)
+ Generates the documentation pages.
+
+enable_java (on/OFF)
+ Generates the java bindings of SimGrid.
+
+enable_jedule (on/OFF)
+ Produces execution traces from SimDag simulations, that can then be visualized with the
+ Jedule external tool.
+
+enable_lua (on/OFF)
+ Generate the lua bindings to the SimGrid internals (requires lua-5.3).
+
+enable_lib_in_jar (ON/off)
+ Embeds the native java bindings into the produced jar file.
+
+enable_lto (ON/off)
+ Enables the *Link Time Optimization* in the C++ compiler.
+ This feature really speeds up the produced code, but it is fragile
+ with older gcc versions.
+
+enable_maintainer_mode (on/OFF)
+ (dev only) Regenerates the XML parsers when the dtd is modified (requires flex and flexml).
+
+enable_mallocators (ON/off)
+ Activates our internal memory caching mechanism. This produces faster
+ code, but it may fool the debuggers.
+
+enable_model-checking (on/OFF)
+ Activates the formal verification mode. This will **hinder
+ simulation speed** even when the model-checker is not activated at
+ run time.
+
+enable_ns3 (on/OFF)
+ Activates the ns-3 bindings. See section @ref pls_ns3.
+
+enable_smpi (ON/off)
+ Allows to run MPI code on top of SimGrid.
+
+enable_smpi_ISP_testsuite (on/OFF)
+ Adds many extra tests for the model-checker module.
+
+enable_smpi_MPICH3_testsuite (on/OFF)
+ Adds many extra tests for the MPI module.
+
+Reset the build configuration
+"""""""""""""""""""""""""""""
+
+To empty the cmake cache (either when you add a new library or when
+things go seriously wrong), simply delete your ``CMakeCache.txt``. You
+may also want to directly edit this file in some circumstances.
+
+.. _install_cmake_outsrc:
+
+Out of Tree Compilation
+^^^^^^^^^^^^^^^^^^^^^^^
+
+By default, the files produced during the compilation are placed in
+the source directory. It is however often better to put them all in a
+separate directory: cleaning the tree becomes as easy as removing this
+directory, and you can have several such directories to test several
+parameter sets or architectures.
+
+For that, go to the directory where the files should be produced, and
+invoke cmake (or ccmake) with the full path to the SimGrid source as
+last argument.
+
+.. code-block:: shell
+
+ mkdir build
+ cd build
+ cmake [options] ..
+ make
+
+Existing Compilation Targets
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+In most cases, compiling and installing SimGrid is enough:
+
+.. code-block:: shell
+
+ make
+ make install # try "sudo make install" if you don't have the permission to write
+
+In addition, several compilation targets are provided in SimGrid. If
+your system is well configured, the full list of targets is available
+for completion when using the ``Tab`` key. Note that some of the
+existing targets are not really for public consumption so don't worry
+if some stuff doesn't work for you.
+
+make simgrid
+ Build only the SimGrid library and not any example
+make s4u-app-pingpong
+ Build only this example (works for any example)
+make clean
+ Clean the results of a previous compilation
+make install
+ Install the project (doc/ bin/ lib/ include/)
+make uninstall
+ Uninstall the project (doc/ bin/ lib/ include/)
+make dist
+ Build a distribution archive (tar.gz)
+make distcheck
+ Check the dist (make + make dist + tests on the distribution)
+make documentation
+ Create SimGrid documentation
+
+If you want to see what is really happening, try adding ``VERBOSE=1`` to
+your compilation requests:
+
+.. code-block:: shell
+
+ make VERBOSE=1
+
+.. _install_src_test:
+
+Testing your build
+^^^^^^^^^^^^^^^^^^
+
+Once everything is built, you may want to test the result. SimGrid
+comes with an extensive set of regression tests (as described in the
+@ref inside_tests "insider manual"). The tests are run with ``ctest``,
+that comes with CMake. We run them every commit and the results are
+on `our Jenkins <https://ci.inria.fr/simgrid/>`_.
+
+.. code-block:: shell
+
+ ctest # Launch all tests
+ ctest -R s4u # Launch only the tests which name match the string "s4u"
+ ctest -j4 # Launch all tests in parallel, at most 4 concurrent jobs
+ ctest --verbose # Display all details on what's going on
+ ctest --output-on-failure # Only get verbose for the tests that fail
+
+ ctest -R s4u -j4 --output-on-failure # You changed S4U and want to check that you didn't break anything, huh?
+ # That's fine, I do so all the time myself.
+
+.. _install_cmake_mac:
+
+Mac OS X Specifics
+^^^^^^^^^^^^^^^^^^
+
+SimGrid compiles like a charm with clang (version 3.0 or higher) on Mac OS X:
+
+.. code-block:: shell
+
+ cmake -DCMAKE_C_COMPILER=/path/to/clang -DCMAKE_CXX_COMPILER=/path/to/clang++ .
+ make
+
+
+Troubleshooting your Mac OS X build.
+
+CMake Error: Parse error in cache file build_dir/CMakeCache.txt. Offending entry: /SDKs/MacOSX10.8.sdk
+ This was reported with the XCode version of clang 4.1. The work
+ around is to edit the ``CMakeCache.txt`` file directly, to change
+ the following entry:
+
+ ``CMAKE_OSX_SYSROOT:PATH=/Applications/XCode.app/Contents/Developer/Platforms/MacOSX.platform/Developer``
+
+ You can safely ignore the warning about "-pthread" not being used, if it appears.
+
+/usr/include does not seem to exist
+ This directory does not exist by default on modern Mac OSX versions,
+ and you may need to create it with ``xcode-select -install``
+
+.. _install_cmake_windows:
+
+Windows Specifics
+^^^^^^^^^^^^^^^^^
+
+The best solution to get SimGrid working on windows is to install the
+Ubuntu subsystem of Windows 10. All of SimGrid (but the model-checker)
+works in this setting.
+
+Native builds not very well supported. Have a look to our `appveypor
+configuration file
+<https://framagit.org/simgrid/simgrid/blob/master/.appveyor.yml>`_ to
+see how we manage to use mingw-64 to build the DLL that the Java file
+needs.
+
+The drawback of MinGW-64 is that the produced DLL are not compatible
+with MS Visual C. `clang-cl <http://clang.llvm.org/docs/MSVCCompatibility.html">`_
+sounds promising to fix this. If you get something working or if you
+have any other improvement, please @ref community_contact "tell us".
+
+Java Specifics
+^^^^^^^^^^^^^^
+
+Once you have the `full JDK <http://www.oracle.com/technetwork/java/javase/downloads>`_ installed,
+things should be as simple as:
+
+.. code-block:: shell
+
+ cmake -Denable_java=ON .
+ make simgrid-java_jar # Only build the jarfile
+
+After the compilation, the file ```simgrid.jar``` is produced in the
+root directory.
+
+**Troubleshooting Java Builds**
+
+Sometimes, the build system fails to find the JNI headers. First locate them as follows:
+
+.. code-block:: shell
+
+ $ locate jni.h
+ /usr/lib/jvm/java-8-openjdk-amd64/include/jni.h
+ /usr/lib/jvm/java-9-openjdk-amd64/include/jni.h
+ /usr/lib/jvm/java-10-openjdk-amd64/include/jni.h
+
+
+Then, set the JAVA_INCLUDE_PATH environment variable to the right
+path, and relaunch cmake. If you have several version of jni installed
+(as above), pick the one corresponding to the report of
+``javac -version``
+
+.. code-block:: shell
+
+ export JAVA_INCLUDE_PATH=/usr/lib/jvm/java-8-openjdk-amd64/include/
+ cmake -Denable_java=ON .
+ make
+
+Note that the filename ```jni.h``` was removed from the path.
+
+Linux Multi-Arch Specifics
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+On a multiarch x86_64 Linux, it should be possible to compile a 32 bit
+version of SimGrid with something like:
+
+.. code-block:: shell
+
+ CFLAGS=-m32 \
+ CXXFLAGS=-m32 \
+ PKG_CONFIG_LIBDIR=/usr/lib/i386-linux-gnu/pkgconfig/ \
+ cmake . \
+ -DCMAKE_SYSTEM_PROCESSOR=i386 \
+ -DCMAKE_Fortran_COMPILER=/some/path/to/i686-linux-gnu-gfortran \
+ -DGFORTRAN_EXE=/some/path/to/i686-linux-gnu-gfortran \
+ -DCMAKE_Fortran_FLAGS=-m32
+
+If needed, implement ``i686-linux-gnu-gfortran`` as a script:
+
+.. code-block:: shell
+
+ #!/usr/bin/env sh
+ exec gfortran -m32 "$@"
+
--- /dev/null
+.. First introduction
+
+What is SimGrid
+===============
+
+SimGrid is a framework to simulate distributed computer systems.
+
+It can be used to either assess abstract algorithms, or to profile and
+debug real distributed applications. SimGrid enables studies in the
+domains of (data-)Grids, IaaS Clouds, Clusters, High Performance
+Computing, Volunteer Computing and Peer-to-Peer systems.
+
+Technically speaking, SimGrid is a library. It is neither a graphical
+interface nor a command-line simulator running user scripts. The
+interaction with SimGrid is done by writing programs with the exposed
+functions to build your own simulator.
+
+SimGrid offers many features, many options and many possibilities. The
+documentation aims at smoothing the learning curve. But nothing's
+perfect, and this documentation is really no exception here. Please
+help us improving it by reporting any issue that you see and
+proposing the content that is still missing.
+
+SimGrid is a Free Software distributed under the LGPL licence. You are
+thus welcome to use it as you wish, or even to modify and distribute
+your version (as long as your version is as free as ours). It also
+means that SimGrid is developed by a vivid community of users and
+developers. We hope that you will come and join us!
+
+SimGrid is the result of almost 20 years of research from several
+groups, both in France and in the USA. It benefited of many funding
+from various research instances, including the ANR, Inria, CNRS,
+University of Lorraine, University of Hawai'i at Manoa, ENS Rennes and
+many others. Many thanks to our generous sponsors!
+
+Typical Study based on SimGrid
+------------------------------
+
+Any SimGrid study entails the following components:
+
+ - The studied **Application**. This can be either a distributed
+ algorithm described in our simple APIs, or a full featured real
+ parallel application using for example the MPI interface
+ @ref application "(more info)".
+
+ - The **Virtual Platform**. This is a description of a given
+ distributed system (machines, links, disks, clusters, etc). Most of
+ the platform files are written in XML althrough a Lua interface is
+ under development. SimGrid makes it easy to augment the Virtual
+ Platform with a Dynamic Scenario where for example the links are
+ slowed down (because of external usage), the machines fail. You
+ have even support to specify the applicative workload that you want
+ to feed to your application @ref platform "(more info)".
+
+ - The application's **Deployment Description**. In SimGrid
+ terminology, the application is an inert set of source files and
+ binaries. To make it run, you have to describe how your application
+ should be deployed on the virtual platform. You need to specify
+ which process is mapped on which host, along with their parameters
+ @ref deployment "(more info)".
+
+ - The **Platform Models**. They describe how the virtual platform
+ reacts to the actions of the application. For example, they compute
+ the time taken by a given communication on the virtual platform.
+ These models are already included in SimGrid, and you only need to
+ pick one and maybe tweak its configuration to get your results
+ @ref models "(more info)".
+
+These components are put together to run a **simulation**, that is an
+experiment or a probe. The result of one or many simulation provides
+an **outcome** (logs, visualization, statistical analysis) that help
+answering the **question** targeted by this study.
+
+The questions that SimGrid can solve include the following:
+
+ - **Compare an Application to another**. This is the classical use
+ case for scientists, who use SimGrid to test how the solution that
+ they contribute compares to the existing solutions from the
+ literature.
+
+ - **Design the best Virtual Platform for a given Application.**
+ Tweaking the platform file is much easier than building a new real
+ platform for testing purpose. SimGrid also allows co-design of the
+ platform and the application by modifying both of them.
+
+ - **Debug Real Applications**. With real systems, is sometimes
+ difficult to reproduce the exact run leading to the bug that you
+ are tracking. SimGrid gives you experimental reproducibility,
+ clairevoyance (you can explore every part of the system, and your
+ probe will not change the simulated state). It also makes it easy
+ to mock some parts of the real system that are not under study.
+
+Depending on the context, you may see some parts of this process as
+less important, but you should pay close attention if you want to be
+confident in the results coming out of your simulations. In
+particular, you should not trust blindly your results but always
+strive to double-check them. Likewise, you should question the realism
+of your input configuration, and we even encourage you to doubt (and
+check) the provided performance models.
+
+To ease such questionning, you really should logically separate these
+parts in your experimental setup. It is seen as a very bad practice to
+merge the application, the platform and the deployment all together.
+SimGrid is versatile and your milleage may vary, but you should start
+with your Application specified as a C++ or Java program, using one of
+the provided XML platform file, and with your deployment in a separate
+XML file.
+
+SimGrid Execution Modes
+-----------------------
+
+Depending on the intended study, SimGrid can be run in several execution modes.
+
+** **Simulation Mode**. This is the most common execution mode, where you want
+to study how your application behaves on the virtual platform under
+the experimental scenario.
+
+In this mode, SimGrid can provide information about the time taken by
+your application, the amount of energy dissipated by the platform to
+run your application and the detailed usage of each resource.
+
+** **Model-Checking Mode**. This can be seen as a sort of exhaustive
+testing mode, where every possible outcome of your application is
+explored. In some sense, this mode tests your application for all
+possible platforms that you could imagine (and more).
+
+You just provide the application and its deployment (amount of
+processes and parameters), and the model-checker will litterally
+explore all possible outcomes by testing all possible message
+interleavings: if at some point a given process can either receive the
+message A first or the message B depending on the platform
+characteristics, the model-checker will explore the scenario where A
+arrives first, and then rewind to the same point to explore the
+scenario where B arrives first.
+
+This is a very powerful mode, where you can evaluate the correction of
+your application. It can verify either **safety properties** (asserts)
+or **liveless properties** stating for example that if a given event
+occures, then another given event will occur in a finite amount of
+steps. This mode is not only usable with the abstract algorithms
+developed on top of the SimGrid APIs, but also with real MPI
+applications (to some extend).
+
+The main limit of Model Checking lays in the huge amount of scenarios
+to explore. SimGrid tries to explore only non-redundent scenarios
+thanks to classical reduction techniques (such as DPOR and stateful
+exploration) but the exploration may well never finish if you don't
+carefully adapt your application to this mode.
+
+A classical trap is that the Model Checker can only verify whether
+your application fits the provided properties, which is useless if you
+have a bug in your property. Remember also that one way for your
+application to never violate a given assert is to not start at all
+because of a stupid bug.
+
+Another limit of this mode is that it does not use the performance
+models of the simulation mode. Time becomes discrete: You can say for
+example that the application took 42 steps to run, but there is no way
+to know the amount of seconds that it took or the amount of watts that
+it dissipated.
+
+Finally, the model checker only explores the interleavings of
+computations and communications. Other factors such as thread
+execution interleaving are not considered by the SimGrid model
+checker.
+
+The model checker may well miss existing issues, as it computes the
+possible outcomes *from a given initial situation*. There is no way to
+prove the correction of your application in all generality with this
+tool.
+
+** **Benchmark Recording Mode**. During debug sessions, continuous
+integration testing and other similar use cases, you are often only
+interested in the control flow. If your application apply filters to
+huge images split in small blocks, the filtered image is probably not
+what you are interested in. You are probably looking for a way to run
+each computation kernel only once, save on disk the time it takes and
+some other metadata. This code block can then be skipped in simulation
+and replaced by a synthetic block using the cached information. The
+virtual platform will take this block into account without requesting
+the real hosting machine to benchmark it.
+
+SimGrid Limits
+--------------
+
+This framework is by no means the perfect holly grail able to solve
+every problem on earth.
+
+** **SimGrid scope is limited to distributed systems.** Real-time
+multithreaded systems are not in the scope. You could probably tweak
+SimGrid for such studies (or the framework could possibily be extended
+in this direction), but another framework specifically targeting this
+usecase would probably be more suited.
+
+** **There is currently no support for IoT studies and wireless networks**.
+The framework could certainly be improved in this direction, but this
+is still to be done.
+
+** **There is no perfect model, only models adapted to your study.**
+The SimGrid models target fast, large studies yet requesting a
+realistic results. In particular, our models abstract away parameters
+and phenomenon that are often irrelevant to the realism in our
+context.
+
+SimGrid is simply not intended to any study that would mandate the
+abstracted phenomenon. Here are some **studies that you should not do
+with SimGrid**:
+
+ - Studying the effect of L3 vs L2 cache effects on your application
+ - Comparing variantes of TCP
+ - Exploring pathological cases where TCP breaks down, resulting in
+ abnormal executions.
+ - Studying security aspects of your application, in presence of
+ malicious agents.
+
+SimGrid Success Stories
+-----------------------
+
+SimGrid was cited in over 1,500 scientific papers (according to Google
+Scholar). Among them
+<a href="http://simgrid.gforge.inria.fr/Usages.php">over 200
+publications</a> (written by about 300 individuals) use SimGrid as a
+scientific instrument to conduct their experimental evaluation. These
+numbers do not count the articles contributing to SimGrid.
+This instrument was used in many research communities, such as
+<a href="https://hal.inria.fr/inria-00580599/">High-Performance Computing</a>,
+<a href="http://dx.doi.org/10.1109/CLOUD.2015.125">Cloud Computing</a>,
+<a href="http://dl.acm.org/citation.cfm?id=2310096.2310195">Workflow Scheduling</a>,
+<a href="https://hal.inria.fr/hal-01199200/">Big Data</a> and
+<a href="http://dx.doi.org/10.1109/WSCAD-SSC.2012.18">MapReduce</a>,
+<a href="http://ieeexplore.ieee.org/document/7515695/">Data Grid</a>,
+<a href="http://www.sciencedirect.com/science/article/pii/S1569190X17301028">Volunteer Computing</a>,
+<a href="https://hal.archives-ouvertes.fr/hal-01152469/">Peer-to-Peer Computing</a>,
+<a href="http://dx.doi.org/10.1109/TPDS.2016.2613043">Network Architecture</a>,
+<a href="http://ieeexplore.ieee.org/document/7946412/">Fog Computing</a>, or
+<a href="https://hal.archives-ouvertes.fr/hal-01333471">Batch Scheduling</a>
+<a href="http://simgrid.gforge.inria.fr/Usages.php"><b>(more info)</b></a>.
+
+If your platform description is accurate enough (see
+<a href="http://hal.inria.fr/hal-00907887">here</a> or
+<a href="https://hal.inria.fr/hal-01523608">there</a>),
+SimGrid can provide high-quality performance predictions. For example,
+we determined the speedup achieved by the Tibidabo Arm-based
+cluster before its construction
+(<a href="http://hal.inria.fr/hal-00919507">paper</a>). In this case,
+some differences between the prediction and the real timings were due to
+misconfiguration or other problems with the real platforms. To some extent,
+SimGrid could even be used to debug the real platform :)
+
+SimGrid is also used to debug, improve and tune several large
+applications.
+<a href="http://bigdft.org">BigDFT</a> (a massively parallel code
+computing the electronic structure of chemical elements developped by
+the CEA), <a href="http://starpu.gforge.inria.fr/">StarPU</a> (a
+Unified Runtime System for Heterogeneous Multicore Architectures
+developped by Inria Bordeaux) and
+<a href="https://tomp2p.net/dev/simgrid/">TomP2P</a> (a high performance
+key-value pair storage library developped at University of Zurich).
+Some of these applications enjoy large user communities themselves.
+
+Where to proceed next?
+----------------------
+
+Now that you know about the basic concepts of SimGrid, you can give it
+a try. If it's not done yet, first @ref install "install it". Then,
+proceed to the section on @ref application "describing the application" that
+you want to study.
action.latency_ = 0.0;
}
}
- action.update_remains(action.get_cost() * delta / action.initialLatency_);
+ action.update_remains(action.get_cost() * delta / action.initial_latency_);
if (action.get_max_duration() != NO_MAX_DURATION)
action.update_max_duration(delta);
* Action *
**********/
NetworkConstantAction::NetworkConstantAction(NetworkConstantModel* model_, double size, double latency)
- : NetworkAction(model_, size, false), initialLatency_(latency)
+ : NetworkAction(model_, size, false), initial_latency_(latency)
{
latency_ = latency;
if (latency_ <= 0.0)
namespace kernel {
namespace resource {
-/***********
- * Classes *
- ***********/
-
-class XBT_PRIVATE NetworkConstantModel;
-class XBT_PRIVATE NetworkConstantAction;
-
-/*********
- * Model *
- *********/
class NetworkConstantModel : public NetworkModel {
public:
NetworkConstantModel();
LinkImpl* create_link(const std::string& name, double bw, double lat, s4u::Link::SharingPolicy policy) override;
};
-/**********
- * Action *
- **********/
class NetworkConstantAction : public NetworkAction {
public:
NetworkConstantAction(NetworkConstantModel* model_, double size, double latency);
~NetworkConstantAction();
- double initialLatency_;
+ double initial_latency_;
void update_remains_lazy(double now) override;
};
-}
+
+} // namespace resource
} // namespace kernel
} // namespace simgrid
* Crude globals *
*****************/
-extern std::map<std::string, SgFlow*> flowFromSock;
+extern std::map<std::string, SgFlow*> flow_from_sock;
static ns3::InternetStackHelper stack;
static ns3::NodeContainer nodes;
NetPointNs3::NetPointNs3()
{
- ns3Node_ = ns3::CreateObject<ns3::Node>(0);
- stack.Install(ns3Node_);
- nodes.Add(ns3Node_);
+ ns3_node_ = ns3::CreateObject<ns3::Node>(0);
+ stack.Install(ns3_node_);
+ nodes.Add(ns3_node_);
node_num = number_of_nodes++;
}
return;
}
- std::string ns3Socket;
- for (auto elm : flowFromSock) {
- ns3Socket = elm.first;
+ std::string ns3_socket;
+ for (auto elm : flow_from_sock) {
+ ns3_socket = elm.first;
SgFlow* sgFlow = elm.second;
NetworkNS3Action * action = sgFlow->action_;
XBT_DEBUG("Processing socket %p (action %p)",sgFlow,action);
- action->set_remains(action->get_cost() - sgFlow->sentBytes_);
+ action->set_remains(action->get_cost() - sgFlow->sent_bytes_);
if (TRACE_is_enabled() && action->get_state() == kernel::resource::Action::State::STARTED) {
- double data_delta_sent = sgFlow->sentBytes_ - action->lastSent_;
+ double data_delta_sent = sgFlow->sent_bytes_ - action->last_sent_;
std::vector<LinkImpl*> route = std::vector<LinkImpl*>();
TRACE_surf_resource_set_utilization("LINK", "bandwidth_used", link->get_cname(), action->get_category(),
(data_delta_sent) / delta, now - delta, delta);
- action->lastSent_ = sgFlow->sentBytes_;
+ action->last_sent_ = sgFlow->sent_bytes_;
}
if(sgFlow->finished_){
- socket_to_destroy.push_back(ns3Socket);
- XBT_DEBUG("Destroy socket %p of action %p", ns3Socket.c_str(), action);
+ socket_to_destroy.push_back(ns3_socket);
+ XBT_DEBUG("Destroy socket %p of action %p", ns3_socket.c_str(), action);
action->finish(kernel::resource::Action::State::FINISHED);
} else {
- XBT_DEBUG("Socket %p sent %u bytes out of %u (%u remaining)", ns3Socket.c_str(), sgFlow->sentBytes_,
- sgFlow->totalBytes_, sgFlow->remaining_);
+ XBT_DEBUG("Socket %p sent %u bytes out of %u (%u remaining)", ns3_socket.c_str(), sgFlow->sent_bytes_,
+ sgFlow->total_bytes_, sgFlow->remaining_);
}
}
while (not socket_to_destroy.empty()) {
- ns3Socket = socket_to_destroy.back();
+ ns3_socket = socket_to_destroy.back();
socket_to_destroy.pop_back();
- SgFlow* flow = flowFromSock.at(ns3Socket);
+ SgFlow* flow = flow_from_sock.at(ns3_socket);
if (XBT_LOG_ISENABLED(ns3, xbt_log_priority_debug)) {
- XBT_DEBUG("Removing socket %p of action %p", ns3Socket.c_str(), flow->action_);
+ XBT_DEBUG("Removing socket %p of action %p", ns3_socket.c_str(), flow->action_);
}
delete flow;
- flowFromSock.erase(ns3Socket);
+ flow_from_sock.erase(ns3_socket);
}
}
unsigned int node1 = src->pimpl_netpoint->extension<NetPointNs3>()->node_num;
unsigned int node2 = dst->pimpl_netpoint->extension<NetPointNs3>()->node_num;
- ns3::Ptr<ns3::Node> src_node = src->pimpl_netpoint->extension<NetPointNs3>()->ns3Node_;
- ns3::Ptr<ns3::Node> dst_node = dst->pimpl_netpoint->extension<NetPointNs3>()->ns3Node_;
+ ns3::Ptr<ns3::Node> src_node = src->pimpl_netpoint->extension<NetPointNs3>()->ns3_node_;
+ ns3::Ptr<ns3::Node> dst_node = dst->pimpl_netpoint->extension<NetPointNs3>()->ns3_node_;
xbt_assert(node2 < IPV4addr.size(), "Element %s is unknown to NS3. Is it connected to any one-hop link?",
dst->pimpl_netpoint->get_cname());
ns3::Ptr<ns3::Socket> sock = ns3::Socket::CreateSocket(src_node, ns3::TcpSocketFactory::GetTypeId());
- flowFromSock.insert({transformSocketPtr(sock), new SgFlow(totalBytes, this)});
+ flow_from_sock.insert({transform_socket_ptr(sock), new SgFlow(totalBytes, this)});
sock->Bind(ns3::InetSocketAddress(port_number));
- ns3::Simulator::ScheduleNow(&StartFlow, sock, addr.c_str(), port_number);
+ ns3::Simulator::ScheduleNow(&start_flow, sock, addr.c_str(), port_number);
port_number++;
xbt_assert(port_number <= 65000, "Too many connections! Port number is saturated.");
int srcNum = src->node_num;
int dstNum = dst->node_num;
- ns3::Ptr<ns3::Node> a = src->ns3Node_;
- ns3::Ptr<ns3::Node> b = dst->ns3Node_;
+ ns3::Ptr<ns3::Node> a = src->ns3_node_;
+ ns3::Ptr<ns3::Node> b = dst->ns3_node_;
XBT_DEBUG("\tAdd PTP from %d to %d bw:'%f Bps' lat:'%fs'", srcNum, dstNum, bw, lat);
pointToPoint.SetDeviceAttribute("DataRate",
void update_remains_lazy(double now) override;
// private:
- double lastSent_ = 0;
+ double last_sent_ = 0;
s4u::Host* src_;
s4u::Host* dst_;
};
#include <algorithm>
-std::map<std::string, SgFlow*> flowFromSock; // ns3::sock -> SgFlow
+std::map<std::string, SgFlow*> flow_from_sock; // ns3::sock -> SgFlow
static void receive_callback(ns3::Ptr<ns3::Socket> socket);
static void datasent_cb(ns3::Ptr<ns3::Socket> socket, uint32_t dataSent);
SgFlow::SgFlow(uint32_t totalBytes, simgrid::kernel::resource::NetworkNS3Action* action)
{
- totalBytes_ = totalBytes;
+ total_bytes_ = totalBytes;
remaining_ = totalBytes;
action_ = action;
}
static SgFlow* getFlowFromSocket(ns3::Ptr<ns3::Socket> socket)
{
- auto it = flowFromSock.find(transformSocketPtr(socket));
- return (it == flowFromSock.end()) ? nullptr : it->second;
+ auto it = flow_from_sock.find(transform_socket_ptr(socket));
+ return (it == flow_from_sock.end()) ? nullptr : it->second;
}
static void receive_callback(ns3::Ptr<ns3::Socket> socket)
{
SgFlow* flow = getFlowFromSocket(socket);
- XBT_DEBUG("received on F[%p, total: %u, remain: %u]", flow, flow->totalBytes_, flow->remaining_);
+ XBT_DEBUG("received on F[%p, total: %u, remain: %u]", flow, flow->total_bytes_, flow->remaining_);
if (flow->finished_ == false) {
flow->finished_ = true;
- XBT_DEBUG("recv_cb of F[%p, %p, %u]", flow, flow->action_, flow->totalBytes_);
+ XBT_DEBUG("recv_cb of F[%p, %p, %u]", flow, flow->action_, flow->total_bytes_);
XBT_DEBUG("Stop simulator at %f seconds", ns3::Simulator::Now().GetSeconds());
ns3::Simulator::Stop(ns3::Seconds(0.0));
ns3::Simulator::Run();
static void send_cb(ns3::Ptr<ns3::Socket> sock, uint32_t txSpace)
{
SgFlow* flow = getFlowFromSocket(sock);
- XBT_DEBUG("Asked to write on F[%p, total: %u, remain: %u]", flow, flow->totalBytes_, flow->remaining_);
+ XBT_DEBUG("Asked to write on F[%p, total: %u, remain: %u]", flow, flow->total_bytes_, flow->remaining_);
if (flow->remaining_ == 0) // all data was already buffered (and socket was already closed)
return;
/* While not all is buffered and there remain space in the buffers */
- while (flow->bufferedBytes_ < flow->totalBytes_ && sock->GetTxAvailable() > 0) {
+ while (flow->buffered_bytes_ < flow->total_bytes_ && sock->GetTxAvailable() > 0) {
// Send at most 1040 bytes (data size in a TCP packet), as NS3 seems to not split correctly by itself
uint32_t toWrite = std::min({flow->remaining_, sock->GetTxAvailable(), std::uint32_t(1040)});
int amountSent = sock->Send(0, toWrite, 0);
xbt_assert(amountSent > 0, "Since TxAvailable>0, amountSent should also >0");
- flow->bufferedBytes_ += amountSent;
+ flow->buffered_bytes_ += amountSent;
flow->remaining_ -= amountSent;
XBT_DEBUG("%f: sent %d bytes over flow %p (still %u to go)", ns3::Simulator::Now().GetSeconds(), amountSent, flow,
flow->remaining_);
}
- if (flow->bufferedBytes_ >= flow->totalBytes_)
+ if (flow->buffered_bytes_ >= flow->total_bytes_)
sock->Close();
}
{
/* The tracing wants to know */
SgFlow* flow = getFlowFromSocket(socket);
- flow->sentBytes_ += dataSent;
- XBT_DEBUG("datasent_cb of F[%p, %p, %u] %u sent (%u total)", flow, flow->action_, flow->totalBytes_, dataSent,
- flow->sentBytes_);
+ flow->sent_bytes_ += dataSent;
+ XBT_DEBUG("datasent_cb of F[%p, %p, %u] %u sent (%u total)", flow, flow->action_, flow->total_bytes_, dataSent,
+ flow->sent_bytes_);
}
static void normalClose_callback(ns3::Ptr<ns3::Socket> socket)
{
SgFlow* flow = getFlowFromSocket(socket);
- XBT_DEBUG("normalClose_cb of F[%p, %p, %u]", flow, flow->action_, flow->totalBytes_);
+ XBT_DEBUG("normalClose_cb of F[%p, %p, %u]", flow, flow->action_, flow->total_bytes_);
receive_callback(socket);
}
static void errorClose_callback(ns3::Ptr<ns3::Socket> socket)
{
SgFlow* flow = getFlowFromSocket(socket);
- XBT_DEBUG("errorClose_cb of F[%p, %p, %u]", flow, flow->action_, flow->totalBytes_);
+ XBT_DEBUG("errorClose_cb of F[%p, %p, %u]", flow, flow->action_, flow->total_bytes_);
xbt_die("NS3: a socket was closed anormally");
}
static void succeededConnect_callback(ns3::Ptr<ns3::Socket> socket)
{
SgFlow* flow = getFlowFromSocket(socket);
- XBT_DEBUG("succeededConnect_cb of F[%p, %p, %u]", flow, flow->action_, flow->totalBytes_);
+ XBT_DEBUG("succeededConnect_cb of F[%p, %p, %u]", flow, flow->action_, flow->total_bytes_);
}
static void failedConnect_callback(ns3::Ptr<ns3::Socket> socket)
{
SgFlow* mysocket = getFlowFromSocket(socket);
- XBT_DEBUG("failedConnect_cb of F[%p, %p, %u]", mysocket, mysocket->action_, mysocket->totalBytes_);
+ XBT_DEBUG("failedConnect_cb of F[%p, %p, %u]", mysocket, mysocket->action_, mysocket->total_bytes_);
xbt_die("NS3: a socket failed to connect");
}
-void StartFlow(ns3::Ptr<ns3::Socket> sock, const char* to, uint16_t port_number)
+void start_flow(ns3::Ptr<ns3::Socket> sock, const char* to, uint16_t port_number)
{
SgFlow* flow = getFlowFromSocket(sock);
ns3::InetSocketAddress serverAddr(to, port_number);
// Notice when we actually sent some data (mostly for the TRACING module)
sock->SetDataSentCallback(MakeCallback(&datasent_cb));
- XBT_DEBUG("startFlow of F[%p, %p, %u] dest=%s port=%d", flow, flow->action_, flow->totalBytes_, to, port_number);
+ XBT_DEBUG("startFlow of F[%p, %p, %u] dest=%s port=%d", flow, flow->action_, flow->total_bytes_, to, port_number);
sock->SetConnectCallback(MakeCallback(&succeededConnect_callback), MakeCallback(&failedConnect_callback));
sock->SetCloseCallbacks(MakeCallback(&normalClose_callback), MakeCallback(&errorClose_callback));
explicit NetPointNs3();
int node_num;
- ns3::Ptr<ns3::Node> ns3Node_;
+ ns3::Ptr<ns3::Node> ns3_node_;
};
XBT_PUBLIC void ns3_initialize(std::string TcpProtocol);
SgFlow(uint32_t total_bytes, simgrid::kernel::resource::NetworkNS3Action* action);
// private:
- std::uint32_t bufferedBytes_ = 0;
- std::uint32_t sentBytes_ = 0;
+ std::uint32_t buffered_bytes_ = 0;
+ std::uint32_t sent_bytes_ = 0;
std::uint32_t remaining_;
- std::uint32_t totalBytes_;
+ std::uint32_t total_bytes_;
bool finished_ = false;
simgrid::kernel::resource::NetworkNS3Action* action_;
};
-void StartFlow(ns3::Ptr<ns3::Socket> sock, const char* to, uint16_t port_number);
+void start_flow(ns3::Ptr<ns3::Socket> sock, const char* to, uint16_t port_number);
-static inline std::string transformSocketPtr(ns3::Ptr<ns3::Socket> local_socket)
+static inline std::string transform_socket_ptr(ns3::Ptr<ns3::Socket> local_socket)
{
std::stringstream sstream;
sstream << local_socket;