--- a/doc/manual/source/distributed.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/distributed.rst Fri May 06 13:21:20 2011 -0700
@@ -149,12 +149,12 @@
./waf shell
cd build/debug
- mpirun -np 2 examples/mpi/simple-distributed
+ mpirun -np 2 src/mpi/examples/simple-distributed
Creating custom topologies
++++++++++++++++++++++++++
-The example programs in examples/mpi give a good idea of how to create different
+The example programs in src/mpi/examples give a good idea of how to create different
topologies for distributed simulation. The main points are assigning system ids
to individual nodes, creating point-to-point links where the simulation should
be divided, and installing applications only on the LP associated with the
--- a/doc/manual/source/emu.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/emu.rst Fri May 06 13:21:20 2011 -0700
@@ -141,8 +141,8 @@
EmuHelper::EnablePcapAll ("emu-udp-echo-client");
-To see an example of a client script using the ``Emu`` net device, see
-``examples/emu-udp-echo-client.cc`` and ``examples/emu-udp-echo-server.cc``
+For examples that use the ``Emu`` net device, see
+``src/emu/examples/emu-udp-echo.cc`` and ``src/emu/examples/emu-ping.cc``
in the repository `<http://code.nsnam.org/craigdo/ns-3-emu/>`_.
Implementation
--- a/doc/manual/source/energy.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/energy.rst Fri May 06 13:21:20 2011 -0700
@@ -7,13 +7,13 @@
Model Description
=================
-The source code for the Energy Framework is currently at: ``src/contrib/energy``.
+The source code for the Energy Framework is currently at: ``src/energy``.
Design
******
The ns-3 Energy Framework is composed of 2 parts: Energy Source and Device Energy Model.
-The framework will be implemented into the ``src/contrib/energy/models`` folder.
+The framework will be implemented into the ``src/energy/models`` folder.
Energy Source
#############
@@ -59,7 +59,7 @@
Usage
=====
-The main way that ns-3 users will typically interact with the Energy Framework is through the helper API and through the publicly visible attributes of the framework. The helper API is defined in ``src/contrib/energy/helper/*.h``.
+The main way that ns-3 users will typically interact with the Energy Framework is through the helper API and through the publicly visible attributes of the framework. The helper API is defined in ``src/energy/helper/*.h``.
In order to use the energy framework, the user must install an Energy Source for the node of interest and the corresponding Device Energy Model for the network devices. Energy Source (objects) are aggregated onto each node by the Energy Source Helper. In order to allow multiple energy sources per node, we aggregate an Energy Source Container rather than directly aggregating a source object.
@@ -69,7 +69,9 @@
Examples
********
-The example ``examples/energy/`` contain some basic code that shows how to set up the framework.
+The example directories, ``src/examples/energy`` and
+``examples/energy``, contain some basic code that shows how to set up
+the framework.
Helpers
*******
--- a/doc/manual/source/flow-monitor.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/flow-monitor.rst Fri May 06 13:21:20 2011 -0700
@@ -3,6 +3,7 @@
*Placeholder chapter*
-This feature was added as contributed code (``src/contrib``) in *ns-3.6* and to
-the main distribution for *ns-3.7*. A paper on this feature is published in the
-proceedings of NSTools: `<http://www.nstools.org/techprog.shtml>`_.
+This feature was added as contributed code (``src/contrib``) in
+*ns-3.6* and to the main distribution (``src/flow-monitor``) for
+*ns-3.7*. A paper on this feature is published in the proceedings of
+NSTools: `<http://www.nstools.org/techprog.shtml>`_.
--- a/doc/manual/source/lte.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/lte.rst Fri May 06 13:21:20 2011 -0700
@@ -21,7 +21,7 @@
*****************
The source code for the LTE models lives in the directory
-``src/devices/lte``.
+``src/lte``.
Design
======
@@ -249,16 +249,16 @@
interact with the LTE models is through the helper API and through
the publicly visible attributes of the model.
-The helper API is defined in ``src/devices/lte/helper/lte-helper.h``.
+The helper API is defined in ``src/lte/helper/lte-helper.h``.
-The example ``src/devices/lte/examples/`` contain some basic
+The example ``src/lte/examples/`` contain some basic
code that shows how to set up the model in order to simualte an
E-UTRAN downlink transmission.
Examples
========
-``src/devices/lte/examples/lte-device.cc`` shows how it is possible to set up the LTE module::
+``src/lte/examples/lte-device.cc`` shows how it is possible to set up the LTE module::
NodeContainer ueNodes;
NodeContainer enbNodes;
@@ -352,7 +352,7 @@
Validation
**********
-In the ``src/devices/lte/example/lte-amc.cc`` has been developed an important example
+In the ``src/lte/example/lte-amc.cc`` has been developed an important example
that shows the proper functioning of both AMC module and Channel model.
The analyzed scenario is composed by two nodes: a eNB and a single UE
(registered to the eNB). The UE moves into the cell using the
--- a/doc/manual/source/new-models.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/new-models.rst Fri May 06 13:21:20 2011 -0700
@@ -174,7 +174,7 @@
particularly for ease of integrating with the build system.
In the case of the error model, it is very related to the packet class, so it
-makes sense to implement this in the ``src/common/`` directory where |ns3|
+makes sense to implement this in the ``src/network/model/`` directory where |ns3|
packets are implemented.
waf and wscript
@@ -186,7 +186,7 @@
add your files to the ``wscript`` file found in each directory.
Let's start with empty files error-model.h and error-model.cc, and add this to
-``src/common/wscript``. It is really just a matter of adding the .cc file to the
+``src/network/wscript``. It is really just a matter of adding the .cc file to the
rest of the source files, and the .h file to the list of the header files.
Now, pop up to the top level directory and type "./waf --check". You
@@ -304,8 +304,8 @@
A few things to note here. We need to include ``object.h``. The convention in
|ns3| is that if the header file is co-located in the same directory, it may be
included without any path prefix. Therefore, if we were implementing ErrorModel
-in ``src/core`` directory, we could have just said "``#include "object.h"``".
-But we are in ``src/common``, so we must include it as "``#include
+in ``src/core/model`` directory, we could have just said "``#include "object.h"``".
+But we are in ``src/network/model``, so we must include it as "``#include
"ns3/object.h"``". Note also that this goes outside the namespace declaration.
Second, each class must implement a static public member function called
--- a/doc/manual/source/realtime.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/realtime.rst Fri May 06 13:21:20 2011 -0700
@@ -60,8 +60,8 @@
GlobalValue::Bind ("SimulatorImplementationType",
StringValue ("ns3::RealtimeSimulatorImpl"));
-There is a script in ``examples/realtime-udp-echo.cc`` that has an example of
-how to configure the realtime behavior. Try: ::
+There is a script in ``examples/realtime/realtime-udp-echo.cc`` that
+has an example of how to configure the realtime behavior. Try: ::
./waf --run realtime-udp-echo
--- a/doc/manual/source/routing.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/routing.rst Fri May 06 13:21:20 2011 -0700
@@ -267,7 +267,7 @@
+++++++++++++++++++++++++++++++++++
This IPv4 routing protocol was originally ported from the OLSR-UM implementation
-for ns-2. The implementation is found in the src/routing/olsr directory, and an
+for ns-2. The implementation is found in the src/olsr directory, and an
example script is in examples/simple-point-to-point-olsr.cc.
Typically, OLSR is enabled in a main program by use of an OlsrHelper class that
--- a/doc/manual/source/statistics.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/statistics.rst Fri May 06 13:21:20 2011 -0700
@@ -8,4 +8,4 @@
This wiki page: `This wiki page
<http://www.nsnam.org/wiki/index.php/Statistical_Framework_for_Network_Simulation>`_
contains information about the proposed statistical framework that is located in
-``src/contrib`` directory.
+``src/stats`` directory.
--- a/doc/manual/source/uan.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/uan.rst Fri May 06 13:21:20 2011 -0700
@@ -12,7 +12,7 @@
*****************
The source code for the UAN Framework lives in the directory
-``src/devices/uan``, ``src/devices/uan/auv`` and in ``src/contrib/energy`` for the contribution on
+``src/uan`` and in ``src/energy`` for the contribution on
the li-ion battery model.
The UAN Framework is composed of two main parts:
@@ -26,7 +26,7 @@
Design
======
-The development of the UAN Framework for ns-3 is composed by three consecutive steps. The first one is the development of the AUV simulator, the second one is the development of the UAN energy models and the third one is the integration of such components with the existing modules, UAN module and Energy Model. The module is implemented into the ``/src/contrib/uan`` folder for the part regarding acoustic modem energy model and in ``/src/contrib/uan/auv`` for the part regarding the AUV simulator.
+The development of the UAN Framework for ns-3 is composed by three consecutive steps. The first one is the development of the AUV simulator, the second one is the development of the UAN energy models and the third one is the integration of such components with the existing modules, UAN module and Energy Model. The module is implemented into the ``/src/uan`` folder for the part regarding acoustic modem energy model and the part regarding the AUV simulator.
AUV mobility models
@@ -198,10 +198,10 @@
interact with the UAN Framework is through the helper API and through
the publicly visible attributes of the model.
-The helper API is defined in ``src/devices/uan/helper/acoustic-modem-energy-model-helper.{cc,h}`` and in ``/src/devices/uan/auv/helper/...{cc,h}``.
+The helper API is defined in ``src/uan/helper/acoustic-modem-energy-model-helper.{cc,h}`` and in ``/src/uan/helper/...{cc,h}``.
-The example folder ``src/devices/uan/auv/examples/`` contain some basic code that shows how to set up and use the models.
-further examples can be found into the Unit tests in ``src/devices/uan/auv/test/...cc``
+The example folder ``src/uan/examples/`` contain some basic code that shows how to set up and use the models.
+further examples can be found into the Unit tests in ``src/uan/test/...cc``
Examples
========
@@ -363,7 +363,7 @@
================
Includes test cases for single packet energy consumption, energy depletion, Glider and REMUS energy consumption.
-The unit test can be found in ``src/devices/uan/auv/test/auv-energy-model-test.cc``.
+The unit test can be found in ``src/uan/test/auv-energy-model-test.cc``.
The single packet energy consumption test do the following:
@@ -395,7 +395,7 @@
============
Includes test cases for glider and REMUS mobility models.
-The unit test can be found in ``src/devices/uan/auv/test/auv-mobility-test.cc``.
+The unit test can be found in ``src/uan/test/auv-mobility-test.cc``.
* create a node with glider capabilities
* set a specified velocity vector and verify if the resulting buoyancy is the one that is supposed to be
@@ -415,7 +415,7 @@
====================
Includes test case for Li-Ion energy source.
-The unit test can be found in ``src/contrib/energy/test/li-ion-energy-source-test.cc``.
+The unit test can be found in ``src/energy/test/li-ion-energy-source-test.cc``.
The test case verify that after a well-known discharge time with constant current drain, the cell voltage has followed the datasheet discharge curve [9].
--- a/doc/manual/source/wimax.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/manual/source/wimax.rst Fri May 06 13:21:20 2011 -0700
@@ -77,7 +77,7 @@
The helper API is defined in ``src/helper/wimax-helper.{cc,h}``.
-The example ``examples/wimax/wimax-simple.cc`` contains some basic code that
+The example ``src/wimax/examples/wimax-simple.cc`` contains some basic code that
shows how to set up the model:::
switch (schedType)
@@ -116,7 +116,7 @@
type, the physical layer type, and the device type.
Different variants of ``Install`` are available; for instance, the example
-``examples/wimax/wimax-multicast.cc`` shows how to specify a non-default channel
+``src/wimax/examples/wimax-multicast.cc`` shows how to specify a non-default channel
or propagation model:::
channel = CreateObject<SimpleOfdmWimaxChannel> ();
@@ -133,13 +133,13 @@
scheduler);
Mobility is also supported in the same way as in Wifi models; see the
-``examples/wimax/wimax-multicast.cc``.
+``src/wimax/examples/wimax-multicast.cc``.
Another important concept in WiMAX is that of a service flow. This is a
unidirectional flow of packets with a set of QoS parameters such as traffic
priority, rate, scheduling type, etc. The base station is responsible for
issuing service flow identifiers and mapping them to WiMAX connections. The
-following code from ``examples/wimax/wimax-multicast.cc`` shows how this is
+following code from ``src/wimax/examples/wimax-multicast.cc`` shows how this is
configured from a helper level:::
ServiceFlow MulticastServiceFlow = wimax.CreateServiceFlow (ServiceFlow::SF_DIRECTION_DOWN,
--- a/doc/tutorial/source/tweaking.rst Fri May 06 18:34:24 2011 +0200
+++ b/doc/tutorial/source/tweaking.rst Fri May 06 13:21:20 2011 -0700
@@ -408,7 +408,7 @@
::
- int
+ int
main (int argc, char *argv[])
{
...
--- a/examples/tcp/wscript Fri May 06 18:34:24 2011 +0200
+++ b/examples/tcp/wscript Fri May 06 13:21:20 2011 -0700
@@ -10,7 +10,7 @@
obj.source = 'tcp-nsc-lfn.cc'
obj = bld.create_ns3_program('tcp-nsc-zoo',
- ['csma', 'internet'])
+ ['csma', 'internet', 'applications'])
obj.source = 'tcp-nsc-zoo.cc'
obj = bld.create_ns3_program('tcp-star-server',