formatting cleanup
authorTom Henderson <tomh@tomh.org>
Mon, 03 Jan 2011 14:35:44 -0800
changeset 67664caf532b12c3
parent 6765 7d4e6843e455
child 6767 415711451cc6
formatting cleanup
doc/manual/source/attributes.rst
doc/manual/source/csma.rst
doc/manual/source/new-models.rst
doc/manual/source/organization.rst
doc/manual/source/packets.rst
doc/manual/source/realtime.rst
doc/manual/source/tcp.rst
doc/manual/source/wifi.rst
doc/manual/source/wimax.rst
     1.1 --- a/doc/manual/source/attributes.rst	Mon Jan 03 14:28:18 2011 -0800
     1.2 +++ b/doc/manual/source/attributes.rst	Mon Jan 03 14:35:44 2011 -0800
     1.3 @@ -686,12 +686,10 @@
     1.4  
     1.5      ./waf --command-template="%s --ns3::ConfigStore::Filename=csma-bridge-config.xml
     1.6      --ns3::ConfigStore::Mode=Save --ns3::ConfigStore::FileFormat=Xml" --run scratch/csma-bridge
     1.7 -    @end example
     1.8 -    @end smallformat
     1.9 -    After running, you can open the csma-bridge-config.xml file and it will
    1.10 -    display the configuration that was applied to your simulation; e.g.
    1.11 -    @smallformat
    1.12 -    @example
    1.13 +
    1.14 +After running, you can open the csma-bridge-config.xml file and it will
    1.15 +display the configuration that was applied to your simulation; e.g.::
    1.16 +
    1.17      <?xml version="1.0" encoding="UTF-8"?>
    1.18      <ns3>
    1.19       <default name="ns3::V4Ping::Remote" value="102.102.102.102"/>
     2.1 --- a/doc/manual/source/csma.rst	Mon Jan 03 14:28:18 2011 -0800
     2.2 +++ b/doc/manual/source/csma.rst	Mon Jan 03 14:35:44 2011 -0800
     2.3 @@ -96,7 +96,7 @@
     2.4  The CsmaChannel has three states, ``IDLE``, ``TRANSMITTING`` and
     2.5  ``PROPAGATING``. These three states are "seen" instantaneously by all devices on
     2.6  the channel. By this we mean that if one device begins or ends a simulated
     2.7 -transmission, all devices on the channel are @emph{immediately} aware of the
     2.8 +transmission, all devices on the channel are *immediately* aware of the
     2.9  change in state. There is no time during which one device may see an ``IDLE``
    2.10  channel while another device physically further away in the collision domain may
    2.11  have begun transmitting with the associated signals not propagated down the
     3.1 --- a/doc/manual/source/new-models.rst	Mon Jan 03 14:28:18 2011 -0800
     3.2 +++ b/doc/manual/source/new-models.rst	Mon Jan 03 14:35:44 2011 -0800
     3.3 @@ -514,7 +514,7 @@
     3.4  provides a useful base class interface (Corrupt () and Reset ()), forwarded to
     3.5  virtual functions that can be subclassed. Let's next consider what we call a
     3.6  BasicErrorModel which is based on the |ns2| ErrorModel class (in
     3.7 -ns-2/queue/errmodel.@{cc,h@}).
     3.8 +``ns-2/queue/errmodel.{cc,h}``).
     3.9  
    3.10  What properties do we want this to have, from a user interface perspective? We
    3.11  would like for the user to be able to trivially swap out the type of ErrorModel
     4.1 --- a/doc/manual/source/organization.rst	Mon Jan 03 14:28:18 2011 -0800
     4.2 +++ b/doc/manual/source/organization.rst	Mon Jan 03 14:35:44 2011 -0800
     4.3 @@ -4,8 +4,7 @@
     4.4  Organization
     4.5  ------------
     4.6  
     4.7 -This manual is organized into several parts with several chapters per part.
     4.8 -This chapter describes the overall software organization and the
     4.9 +This chapter describes the overall |ns3| software organization and the
    4.10  corresponding organization of this manual.
    4.11  
    4.12  |ns3| is a discrete-event network simulator in which the simulation core
    4.13 @@ -13,7 +12,7 @@
    4.14  statically or dynamically linked to a C++ main program that defines the
    4.15  simulation topology and starts the simulator. |ns3| also exports nearly all
    4.16  of its API to Python, allowing Python programs to import an "ns3" module in
    4.17 -much the same way as in C++.  
    4.18 +much the same way as the |ns3| library is linked by executables in C++.  
    4.19  
    4.20  .. _software-organization:
    4.21  
    4.22 @@ -26,31 +25,36 @@
    4.23  work our way from the bottom up; in general, modules only have dependencies
    4.24  on modules beneath them in the figure.
    4.25  
    4.26 -We first describe Part 1 of the manual. The simulation core is implemented
    4.27 +We first describe the core of the simulator; those components that are 
    4.28 +common across all protocol, hardware, and environmental models. 
    4.29 +The simulation core is implemented
    4.30  in ``src/core``, and the core is used to build the simulation engine
    4.31  ``src/simulator``. Packets are fundamental objects in a network simulator
    4.32 -and are implemented in ``src/packet``. These three simulation modules by
    4.33 +and are implemented in ``src/common``. These three simulation modules by
    4.34  themselves are intended to comprise a generic simulation core that can be
    4.35  used by different kinds of networks, not just Internet-based networks.  The
    4.36  above modules of |ns3| are independent of specific network and device
    4.37 -models, which are covered in later parts of this manual.
    4.38 +models, which are covered in subsequent parts of this manual.
    4.39  
    4.40 -In addition to the above |ns3| core, we describe also in Part 1 two other
    4.41 -modules that supplement the core C++-based API. |ns3| programs may access
    4.42 +In addition to the above |ns3| core, we introduce, also in the initial 
    4.43 +portion of the manual, two other modules that supplement the core C++-based 
    4.44 +API.  |ns3| programs may access
    4.45  all of the API directly or may make use of a so-called *helper API* that
    4.46  provides convenient wrappers or encapsulation of low-level API calls. The
    4.47  fact that |ns3| programs can be written to two APIs (or a combination
    4.48 -thereof) is a fundamental aspect of the simulator and is also covered in
    4.49 -Part 1.  We also describe how Python is supported in |ns3| as the last
    4.50 -chapter of Part 1. 
    4.51 +thereof) is a fundamental aspect of the simulator.
    4.52 +We also describe how Python is supported in |ns3| before moving onto
    4.53 +specific models of relevance to network simulation.
    4.54  
    4.55  The remainder of the manual is focused on documenting the models and
    4.56 -supporting capabilities.  Part 2 focuses on two fundamental objects in
    4.57 +supporting capabilities.  The next part focuses on two fundamental objects in
    4.58  |ns3|:  the ``Node`` and ``NetDevice``. Two special NetDevice types are
    4.59  designed to support network emulation use cases, and emulation is described
    4.60 -in Part 3. Part 4 is devoted to Internet-related models, including the
    4.61 -sockets API used by Internet applications. Part 5 covers applications, and
    4.62 -Part 6 describes additional support for simulation, such as animators.
    4.63 +next.  The following chapter is devoted to Internet-related models, 
    4.64 +including the
    4.65 +sockets API used by Internet applications. The next chapter covers 
    4.66 +applications, and the following chapter describes additional support for 
    4.67 +simulation, such as animators and statistics.
    4.68  
    4.69  The project maintains a separate manual devoted to testing and validation
    4.70  of |ns3| code (see the `ns-3 Testing and Validation manual
     5.1 --- a/doc/manual/source/packets.rst	Mon Jan 03 14:28:18 2011 -0800
     5.2 +++ b/doc/manual/source/packets.rst	Mon Jan 03 14:35:44 2011 -0800
     5.3 @@ -134,7 +134,7 @@
     5.4  
     5.5  Basically, the first three functions are used to serialize and deserialize
     5.6  protocol control information to/from a Buffer. For example, one may define
     5.7 -@code{class TCPHeader : public Header}. The TCPHeader object will typically
     5.8 +``class TCPHeader : public Header``. The TCPHeader object will typically
     5.9  consist of some private data (like a sequence number) and public interface
    5.10  access functions (such as checking the bounds of an input). But the underlying
    5.11  representation of the TCPHeader in a Packet Buffer is 20 serialized bytes (plus
     6.1 --- a/doc/manual/source/realtime.rst	Mon Jan 03 14:28:18 2011 -0800
     6.2 +++ b/doc/manual/source/realtime.rst	Mon Jan 03 14:35:44 2011 -0800
     6.3 @@ -73,8 +73,8 @@
     6.4  
     6.5  The implementation is contained in the following files:
     6.6  
     6.7 -* ``src/simulator/realtime-simulator-impl.@{cc,h@}``
     6.8 -* ``src/simulator/wall-clock-synchronizer.@{cc,h@}``
     6.9 +* ``src/simulator/realtime-simulator-impl.{cc,h}``
    6.10 +* ``src/simulator/wall-clock-synchronizer.{cc,h}``
    6.11  
    6.12  In order to create a realtime scheduler, to a first approximation you just want
    6.13  to cause simulation time jumps to consume real time. We propose doing this using
     7.1 --- a/doc/manual/source/tcp.rst	Mon Jan 03 14:28:18 2011 -0800
     7.2 +++ b/doc/manual/source/tcp.rst	Mon Jan 03 14:35:44 2011 -0800
     7.3 @@ -15,7 +15,7 @@
     7.4  There are two important abstract base classes:
     7.5  
     7.6  * class :cpp:class:`TcpSocket`:  This is defined in
     7.7 -  ``src/node/tcp-socket.@{cc,h@}``. This class exists for hosting TcpSocket
     7.8 +  ``src/node/tcp-socket.{cc,h}``. This class exists for hosting TcpSocket
     7.9    attributes that can be reused across different implementations. For instance,
    7.10    ``TcpSocket::SetInitialCwnd()`` can be used for any of the implementations
    7.11    that derive from class :cpp:class:`TcpSocket`.
     8.1 --- a/doc/manual/source/wifi.rst	Mon Jan 03 14:28:18 2011 -0800
     8.2 +++ b/doc/manual/source/wifi.rst	Mon Jan 03 14:35:44 2011 -0800
     8.3 @@ -312,14 +312,14 @@
     8.4  distribution and is compared against the probability of error.
     8.5  
     8.6  To evaluate the probability of error, we start from the piecewise linear 
     8.7 -functions shown in Figure @ref{fig:snir} and calculate the 
     8.8 +functions shown in Figure :ref:`snir` and calculate the 
     8.9  SNIR function. 
    8.10  
    8.11  .. _snir:
    8.12  
    8.13  .. figure:: figures/snir.*
    8.14     
    8.15 -   SNIR function over time.
    8.16 +   *SNIR function over time.*
    8.17  
    8.18  From the SNIR function we can derive bit error rates for BPSK and QAM
    8.19  modulations.  Then, for each interval l where BER is constant, we define the
     9.1 --- a/doc/manual/source/wimax.rst	Mon Jan 03 14:28:18 2011 -0800
     9.2 +++ b/doc/manual/source/wimax.rst	Mon Jan 03 14:35:44 2011 -0800
     9.3 @@ -239,7 +239,8 @@
     9.4  :cpp:class:`IpcsClassifierRecord` implement the classifier module for both SS
     9.5  and BS
     9.6   
     9.7 -@subsection MAC Common Part Sublayer
     9.8 +MAC Common Part Sublayer
     9.9 +++++++++++++++++++++++++
    9.10   
    9.11  The MAC Common Part Sublayer (CPS) is the main sublayer of the IEEE 802.16 MAC
    9.12  and performs the fundamental functions of the MAC. The module implements the