F5/unison
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix more paths in the documentation

Browse Source
This commit is contained in:
Mitch Watrous
2011-05-10 11:09:17 -07:00
parent e8a2d1f6d5
commit a861a19dbc
10 changed files with 62 additions and 76 deletions
Download Patch File Download Diff File Expand all files Collapse all files

15
doc/manual/source/internet-stack.rst
View File

@@ -9,7 +9,7 @@ Internet stack aggregation
A bare class :cpp:class:`Node` is not very useful as-is; other objects must be
aggregated to it to provide useful node functionality.
The |ns3| source code directory ``src/internet-stack`` provides implementation
The |ns3| source code directory ``src/internet`` provides implementation
of TCP/IPv4- and IPv6-related components. These include IPv4, ARP, UDP, TCP,
IPv6, Neighbor Discovery, and other related protocols.
@@ -72,9 +72,8 @@ Layer-3 protocols
At the lowest layer, sitting above the NetDevices, are the "layer 3" protocols,
including IPv4, IPv6 (in the future), and ARP. The class
:cpp:class:`Ipv4L3Protocol` is an implementation class whose public interface is
typically class :cpp:class:`Ipv4` (found in src/node directory), but the
Ipv4L3Protocol public API is also used internally in the src/internet-stack
directory at present.
typically class :cpp:class:`Ipv4`, but the
Ipv4L3Protocol public API is also used internally at present.
In class Ipv4L3Protocol, one method described below is ``Receive ()``:::
@@ -199,13 +198,13 @@ Ipv4-capable Node objects are not exposed at the simulator public API. This
allows for different implementations; for instance, replacing the native |ns3|
models with ported TCP/IP stack code.
The C++ public APIs of all of these objects is found in the ``src/node``
The C++ public APIs of all of these objects is found in the ``src/network``
directory, including principally:
* ``address.h``
* ``socket.h``
* ``tcp.h``
* ``udp.h``
* ``ipv4.h``
* ``node.h``
* ``packet.h``
These are typically base class objects that implement the default values used in
the implementation, implement access methods to get/set state variables, host

8
doc/manual/source/packets.rst
View File

@@ -229,7 +229,7 @@ must inherit from class Header, and implement the following methods:
* ``Print ()``
To see a simple example of how these are done, look at the UdpHeader class
headers src/internet-stack/udp-header.cc. There are many other examples within
headers src/internet/udp-header.cc. There are many other examples within
the source code.
Once you have a header (or you have a preexisting header), the following
@@ -291,7 +291,7 @@ will not cover those bytes. The converse is true for the PacketTag; it covers a
packet despite the operations on it.
PacketTags are limited in size to 20 bytes. This is a modifiable compile-time
constant in ``src/common/packet-tag-list.h``. ByteTags have no such restriction.
constant in ``src/network/packet-tag-list.h``. ByteTags have no such restriction.
Each tag type must subclass ``ns3::Tag``, and only one instance of
each Tag type may be in each tag list. Here are a few differences in the
@@ -421,14 +421,14 @@ The Packet API for packet tags is given below.::
PacketTagIterator GetPacketTagIterator (void) const;
Here is a simple example illustrating the use of tags from the
code in ``src/internet-stack/udp-socket-impl.cc``:::
code in ``src/internet/udp-socket-impl.cc``:::
Ptr<Packet> p; // pointer to a pre-existing packet
SocketIpTtlTag tag
tag.SetTtl (m_ipMulticastTtl); // Convey the TTL from UDP layer to IP layer
p->AddPacketTag (tag);
This tag is read at the IP layer, then stripped (``src/internet-stack/ipv4-l3-protocol.cc``):::
This tag is read at the IP layer, then stripped (``src/internet/ipv4-l3-protocol.cc``):::
uint8_t ttl = m_defaultTtl;
SocketIpTtlTag tag;

4
doc/manual/source/realtime.rst
View File

@@ -73,8 +73,8 @@ Implementation
The implementation is contained in the following files:
* ``src/simulator/realtime-simulator-impl.{cc,h}``
* ``src/simulator/wall-clock-synchronizer.{cc,h}``
* ``src/core/realtime-simulator-impl.{cc,h}``
* ``src/core/wall-clock-synchronizer.{cc,h}``
In order to create a realtime scheduler, to a first approximation you just want
to cause simulation time jumps to consume real time. We propose doing this using

2
doc/manual/source/sockets-api.rst
View File

@@ -29,7 +29,7 @@ to understand that the semantics are *not* the exact same as
one finds in a real system (for an API which is very much aligned
to real systems, see the next section).
:cpp:class:`ns3::Socket` is defined in ``src/node/socket.h``.
:cpp:class:`ns3::Socket` is defined in ``src/network/socket.h``.
Readers will note that many public member functions are aligned
with real sockets function calls, and all other things being equal,
we have tried to align with a Posix sockets API. However, note that:

36
doc/manual/source/tcp.rst
View File

@@ -9,13 +9,13 @@ Generic support for TCP
***********************
|ns3| was written to support multiple TCP implementations. The implementations
inherit from a few common header classes in the ``src/node`` directory, so that
inherit from a few common header classes in the ``src/network`` directory, so that
user code can swap out implementations with minimal changes to the scripts.
There are two important abstract base classes:
* class :cpp:class:`TcpSocket`: This is defined in
``src/node/tcp-socket.{cc,h}``. This class exists for hosting TcpSocket
``src/internet/tcp-socket.{cc,h}``. This class exists for hosting TcpSocket
attributes that can be reused across different implementations. For instance,
the attribute ``InitialCwnd`` can be used for any of the implementations
that derive from class :cpp:class:`TcpSocket`.
@@ -42,18 +42,18 @@ connection setup and close logic.
The implementation of TCP is contained in the following files:::
src/internet-stack/tcp-header.{cc,h}
src/internet-stack/tcp-l4-protocol.{cc,h}
src/internet-stack/tcp-socket-factory-impl.{cc,h}
src/internet-stack/tcp-socket-base.{cc,h}
src/internet-stack/tcp-tx-buffer.{cc,h}
src/internet-stack/tcp-rx-buffer.{cc,h}
src/internet-stack/tcp-rfc793.{cc,h}
src/internet-stack/tcp-tahoe.{cc,h}
src/internet-stack/tcp-reno.{cc,h}
src/internet-stack/tcp-newreno.{cc,h}
src/internet-stack/rtt-estimator.{cc,h}
src/common/sequence-number.{cc,h}
src/internet/tcp-header.{cc,h}
src/internet/tcp-l4-protocol.{cc,h}
src/internet/tcp-socket-factory-impl.{cc,h}
src/internet/tcp-socket-base.{cc,h}
src/internet/tcp-tx-buffer.{cc,h}
src/internet/tcp-rx-buffer.{cc,h}
src/internet/tcp-rfc793.{cc,h}
src/internet/tcp-tahoe.{cc,h}
src/internet/tcp-reno.{cc,h}
src/internet/tcp-newreno.{cc,h}
src/internet/rtt-estimator.{cc,h}
src/network/sequence-number.{cc,h}
Different variants of TCP congestion control are supported by subclassing
the common base class :cpp:class:`TcpSocketBase`. Several variants
@@ -66,8 +66,8 @@ Usage
In many cases, usage of TCP is set at the application layer by telling
the |ns3| application which kind of socket factory to use.
Using the helper functions defined in ``src/helper``, here is how
one would create a TCP receiver:::
Using the helper functions defined in ``src/applications/helper`` and
``src/network/helper``, here is how one would create a TCP receiver:::
// Create a packet sink on the star "hub" to receive these packets
uint16_t port = 50000;
@@ -288,7 +288,7 @@ The three main parts are:
* :cpp:class:`ns3::NscTcpSocketFactoryImpl`: a factory to create new NSC
sockets
``src/internet-stack/nsc-tcp-l4-protocol`` is the main class. Upon
``src/internet/nsc-tcp-l4-protocol`` is the main class. Upon
Initialization, it loads an nsc network stack to use (via dlopen()). Each
instance of this class may use a different stack. The stack (=shared library) to
use is set using the SetNscLibrary() method (at this time its called indirectly
@@ -309,7 +309,7 @@ This class calls ``ns3::NscTcpSocketImpl`` both from the nsc wakeup() callback
and from the Receive path (to ensure that possibly queued data is scheduled for
sending).
``src/internet-stack/nsc-tcp-socket-impl`` implements the nsc socket interface.
``src/internet/nsc-tcp-socket-impl`` implements the nsc socket interface.
Each instance has its own nscTcpSocket. Data that is Send() will be handed to
the nsc stack via m_nscTcpSocket->send_data(). (and not to nsc-tcp-l4, this is
the major difference compared to |ns3| TCP). The class also queues up data that

8
doc/manual/source/tracing.rst
View File

@@ -365,7 +365,7 @@ Pcap Tracing Device Helpers
The goal of these helpers is to make it easy to add a consistent pcap trace
facility to an |ns3| device. We want all of the various flavors of pcap tracing
to work the same across all devices, so the methods of these helpers are
inherited by device helpers. Take a look at ``src/helper/trace-helper.h`` if you
inherited by device helpers. Take a look at ``src/network/helper/trace-helper.h`` if you
want to follow the discussion while looking at real code.
The class ``PcapHelperForDevice`` is a ``mixin`` provides the high level
@@ -515,7 +515,7 @@ Ascii Tracing Device Helpers
++++++++++++++++++++++++++++
The behavior of the ascii trace helper ``mixin`` is substantially similar to
the pcap version. Take a look at ``src/helper/trace-helper.h`` if you want to
the pcap version. Take a look at ``src/network/helper/trace-helper.h`` if you want to
follow the discussion while looking at real code.
The class ``AsciiTraceHelperForDevice`` adds the high level functionality for
@@ -721,7 +721,7 @@ Pcap Tracing Protocol Helpers
The goal of these ``mixins`` is to make it easy to add a consistent pcap trace
facility to protocols. We want all of the various flavors of pcap tracing to
work the same across all protocols, so the methods of these helpers are
inherited by stack helpers. Take a look at ``src/helper/trace-helper.h`` if you
inherited by stack helpers. Take a look at ``src/network/helper/trace-helper.h`` if you
want to follow the discussion while looking at real code.
In this section we will be illustrating the methods as applied to the protocol
@@ -858,7 +858,7 @@ Ascii Tracing Protocol Helpers
++++++++++++++++++++++++++++++
The behavior of the ascii trace helpers is substantially similar to the pcap
case. Take a look at ``src/helper/trace-helper.h`` if you want to follow the
case. Take a look at ``src/network/helper/trace-helper.h`` if you want to follow the
discussion while looking at real code.
In this section we will be illustrating the methods as applied to the protocol

2
doc/manual/source/wimax.rst
View File

@@ -75,7 +75,7 @@ The main way that users who write simulation scripts will typically interact
with the Wimax models is through the helper API and through the publicly visible
attributes of the model.
The helper API is defined in ``src/helper/wimax-helper.{cc,h}``.
The helper API is defined in ``src/wimax/helper/wimax-helper.{cc,h}``.
The example ``src/wimax/examples/wimax-simple.cc`` contains some basic code that
shows how to set up the model:::

25
doc/modules
View File

@@ -1,15 +1,12 @@
/**
* @anchor modules_anchor
*
* @defgroup simulator Simulator
* The "simulator" module contains:
* @defgroup core Core
* \brief The "core" module contains:
* - a time management class to hold a time and convert between various time units: ns3::Time
* - a scheduler base class used to implement new simulation event schedulers:
* ns3::Scheduler and ns3::SchedulerFactory
* - a simulator class used to create, schedule and cancel events: ns3::Simulator
*
* @defgroup core Core
* \brief The "core" module contains:
* - a Functor class: ns3::Callback
* - an os-independent interface to get access to the elapsed wall clock time: ns3::SystemWallClockMs
* - a class to register regression tests with the test manager: ns3::Test and ns3::TestManager
@@ -23,15 +20,12 @@
* - a configuration class used to set and control all attributes and trace sources
* in a simulation: ns3::Config.
*
* @defgroup common Common
* The "common" module contains:
* @defgroup network Network
* The "network" module contains:
* - a packet class to create and manipulate simulation packets:
* ns3::Packet, ns3::Header, and ns3::Trailer. This packet class
* also supports per-packet ns3::Tag which are globs of data
* which can be attached to any packet.
*
* @defgroup node Node
* The "node" module contains:
* - a ns3::Node base class which should be subclassed by any new type of
* network Node.
* - models which abstract the MAC-layer from the IP layer protocols:
@@ -39,12 +33,9 @@
* - models which abstract the application-layer API: ns3::Application,
* ns3::Socket, ns3::SocketFactory, and, ns3::Udp
*
*
* @defgroup devices Devices
*
* @defgroup internetStack InternetStack
* @defgroup internet Internet
*
* The "internet-stack" module contains:
* The "internet" module contains:
* - an Ipv4 stack
* - an Ipv6 stack
* - an ARP module
@@ -52,8 +43,6 @@
*
* @defgroup routing Routing
*
* @defgroup helper Helpers
*
* @defgroup applications Applications
*
* @defgroup mobility Mobility
@@ -64,6 +53,4 @@
* @defgroup utils Utils
* @brief The utils directory is for various programs and scripts related
* to code coverage, test suites, style checking, and benchmarking.
*
* @defgroup contrib Contrib
*/

2
doc/tutorial/source/conceptual-overview.rst
View File

@@ -836,5 +836,5 @@ you will find (as of this writing) is ``abort.h``. If you click on the
contains useful macros for exiting scripts if abnormal conditions are detected.
The source code for the helpers we have used in this chapter can be found in the
``src/helper`` directory. Feel free to poke around in the directory tree to
``src/applications/helper`` directory. Feel free to poke around in the directory tree to
get a feel for what is there and the style of |ns3| programs.

36
doc/tutorial/source/tracing.rst
View File

@@ -1178,8 +1178,8 @@ through the list, you will eventually find:
CongestionWindow: The TCP connection's congestion window
It turns out that the |ns3| TCP implementation lives (mostly) in the
file ``src/internet-stack/tcp-socket-base.cc`` while congestion control
variants are in files such as ``src/internet-stack/tcp-newreno.cc``.
file ``src/internet/tcp-socket-base.cc`` while congestion control
variants are in files such as ``src/internet/tcp-newreno.cc``.
If you don't know this a priori, you can use the recursive grep trick:
::
@@ -1188,7 +1188,7 @@ If you don't know this a priori, you can use the recursive grep trick:
You will find page after page of instances of tcp pointing you to that file.
If you open ``src/internet-stack/tcp-newreno.cc`` in your favorite
If you open ``src/internet/tcp-newreno.cc`` in your favorite
editor, you will see right up at the top of the file, the following declarations:
::
@@ -1207,7 +1207,7 @@ editor, you will see right up at the top of the file, the following declarations
}
This should tell you to look for the declaration of ``m_cWnd`` in the header
file ``src/internet-stack/tcp-newreno.h``. If you open this file in your
file ``src/internet/tcp-newreno.h``. If you open this file in your
favorite editor, you will find:
::
@@ -1424,7 +1424,7 @@ we put together to allow the ``Socket`` to be created at configuration time.
};
You can see that this class inherits from the |ns3| ``Application``
class. Take a look at ``src/node/application.h`` if you are interested in
class. Take a look at ``src/network/application.h`` if you are interested in
what is inherited. The ``MyApp`` class is obligated to override the
``StartApplication`` and ``StopApplication`` methods. These methods are
automatically called when ``MyApp`` is required to start and stop sending
@@ -1451,7 +1451,7 @@ This is done as the result of the following (hopefully) familar lines of an
apps.Start (Seconds (1.0));
apps.Stop (Seconds (10.0));
The application container code (see ``src/helper/application-container.h`` if
The application container code (see ``src/network/helper/application-container.h`` if
you are interested) loops through its contained applications and calls,
::
@@ -1482,7 +1482,7 @@ ignore the implementation details of how your ``Application`` is
"automagically" called by the simulator at the correct time. But since
we have already ventured deep into |ns3| already, let's go for it.
If you look at ``src/node/application.cc`` you will find that the
If you look at ``src/network/application.cc`` you will find that the
``SetStartTime`` method of an ``Application`` just sets the member
variable ``m_startTime`` and the ``SetStopTime`` method just sets
``m_stopTime``. From there, without some hints, the trail will probably
@@ -1492,7 +1492,7 @@ The key to picking up the trail again is to know that there is a global
list of all of the nodes in the system. Whenever you create a node in
a simulation, a pointer to that node is added to the global ``NodeList``.
Take a look at ``src/node/node-list.cc`` and search for
Take a look at ``src/network/node-list.cc`` and search for
``NodeList::Add``. The public static implementation calls into a private
implementation called ``NodeListPriv::Add``. This is a relatively common
idom in |ns3|. So, take a look at ``NodeListPriv::Add``. There
@@ -1512,7 +1512,7 @@ to start doing something.
So, ``NodeList::Add`` indirectly schedules a call to ``Node::Start``
at time zero to advise a new node that the simulation has started. If you
look in ``src/node/node.h`` you will, however, not find a method called
look in ``src/network/node.h`` you will, however, not find a method called
``Node::Start``. It turns out that the ``Start`` method is inherited
from class ``Object``. All objects in the system can be notified when
the simulation starts, and objects of class ``Node`` are just one kind
@@ -1530,7 +1530,7 @@ something like ``MethodName`` for the public API and ``DoMethodName`` for
the private API.
This tells us that we should look for a ``Node::DoStart`` method in
``src/node/node.cc`` for the method that will continue our trail. If you
``src/network/node.cc`` for the method that will continue our trail. If you
locate the code, you will find a method that loops through all of the devices
in the node and then all of the applications in the node calling
``device->Start`` and ``application->Start`` respectively.
@@ -1538,7 +1538,7 @@ in the node and then all of the applications in the node calling
You may already know that classes ``Device`` and ``Application`` both
inherit from class ``Object`` and so the next step will be to look at
what happens when ``Application::DoStart`` is called. Take a look at
``src/node/application.cc`` and you will find:
``src/network/application.cc`` and you will find:
::
@@ -2138,7 +2138,7 @@ is going to contain packets prefixed with point to point headers. This is true
since the packets are coming from our point-to-point device driver. Other
common data link types are DLT_EN10MB (10 MB Ethernet) appropriate for csma
devices and DLT_IEEE802_11 (IEEE 802.11) appropriate for wifi devices. These
are defined in ``src/helper/trace-helper.h"`` if you are interested in seeing
are defined in ``src/network/helper/trace-helper.h"`` if you are interested in seeing
the list. The entries in the list match those in ``bpf.h`` but we duplicate
them to avoid a pcap source dependence.
@@ -2161,7 +2161,7 @@ pointer to a reference counted object that is a very lightweight thing.
Remember to always look at the object you are referencing before making any
assumptions about the "powers" that object may have.
For example, take a look at ``src/common/pcap-file-object.h`` in the
For example, take a look at ``src/network/pcap-file-object.h`` in the
distribution and notice,
::
@@ -2169,7 +2169,7 @@ distribution and notice,
class PcapFileWrapper : public Object
that class ``PcapFileWrapper`` is an |ns3| Object by virtue of
its inheritance. Then look at ``src/common/output-stream-wrapper.h`` and
its inheritance. Then look at ``src/network/output-stream-wrapper.h`` and
notice,
::
@@ -2327,7 +2327,7 @@ The goal of these helpers is to make it easy to add a consistent pcap trace
facility to an |ns3| device. We want all of the various flavors of
pcap tracing to work the same across all devices, so the methods of these
helpers are inherited by device helpers. Take a look at
``src/helper/trace-helper.h`` if you want to follow the discussion while
``src/network/helper/trace-helper.h`` if you want to follow the discussion while
looking at real code.
The class ``PcapHelperForDevice`` is a ``mixin`` provides the high level
@@ -2500,7 +2500,7 @@ Ascii Tracing Device Helpers
++++++++++++++++++++++++++++
The behavior of the ascii trace helper ``mixin`` is substantially similar to
the pcap version. Take a look at ``src/helper/trace-helper.h`` if you want to
the pcap version. Take a look at ``src/network/helper/trace-helper.h`` if you want to
follow the discussion while looking at real code.
The class ``AsciiTraceHelperForDevice`` adds the high level functionality for
@@ -2743,7 +2743,7 @@ Pcap Tracing Protocol Helpers
The goal of these ``mixins`` is to make it easy to add a consistent pcap trace
facility to protocols. We want all of the various flavors of pcap tracing to
work the same across all protocols, so the methods of these helpers are
inherited by stack helpers. Take a look at ``src/helper/trace-helper.h``
inherited by stack helpers. Take a look at ``src/network/helper/trace-helper.h``
if you want to follow the discussion while looking at real code.
In this section we will be illustrating the methods as applied to the protocol
@@ -2909,7 +2909,7 @@ Ascii Tracing Protocol Helpers
++++++++++++++++++++++++++++++
The behavior of the ascii trace helpers is substantially similar to the pcap
case. Take a look at ``src/helper/trace-helper.h`` if you want to
case. Take a look at ``src/network/helper/trace-helper.h`` if you want to
follow the discussion while looking at real code.
In this section we will be illustrating the methods as applied to the protocol