From a861a19dbc54d715faf38bed991c3a645fdadef8 Mon Sep 17 00:00:00 2001 From: Mitch Watrous Date: Tue, 10 May 2011 11:09:17 -0700 Subject: [PATCH] Fix more paths in the documentation --- doc/manual/source/internet-stack.rst | 15 ++++----- doc/manual/source/packets.rst | 8 ++--- doc/manual/source/realtime.rst | 4 +-- doc/manual/source/sockets-api.rst | 2 +- doc/manual/source/tcp.rst | 36 ++++++++++----------- doc/manual/source/tracing.rst | 8 ++--- doc/manual/source/wimax.rst | 2 +- doc/modules | 25 ++++---------- doc/tutorial/source/conceptual-overview.rst | 2 +- doc/tutorial/source/tracing.rst | 36 ++++++++++----------- 10 files changed, 62 insertions(+), 76 deletions(-) diff --git a/doc/manual/source/internet-stack.rst b/doc/manual/source/internet-stack.rst index 66dfb4e17..23582c735 100644 --- a/doc/manual/source/internet-stack.rst +++ b/doc/manual/source/internet-stack.rst @@ -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 diff --git a/doc/manual/source/packets.rst b/doc/manual/source/packets.rst index db78049f6..7640b621a 100644 --- a/doc/manual/source/packets.rst +++ b/doc/manual/source/packets.rst @@ -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 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; diff --git a/doc/manual/source/realtime.rst b/doc/manual/source/realtime.rst index aec84ff10..fe134db46 100644 --- a/doc/manual/source/realtime.rst +++ b/doc/manual/source/realtime.rst @@ -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 diff --git a/doc/manual/source/sockets-api.rst b/doc/manual/source/sockets-api.rst index 22fcfab0e..cafbe111d 100644 --- a/doc/manual/source/sockets-api.rst +++ b/doc/manual/source/sockets-api.rst @@ -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: diff --git a/doc/manual/source/tcp.rst b/doc/manual/source/tcp.rst index 244ea5a05..bfcf695aa 100644 --- a/doc/manual/source/tcp.rst +++ b/doc/manual/source/tcp.rst @@ -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 diff --git a/doc/manual/source/tracing.rst b/doc/manual/source/tracing.rst index d1f4ef6c5..9f138bfb2 100644 --- a/doc/manual/source/tracing.rst +++ b/doc/manual/source/tracing.rst @@ -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 diff --git a/doc/manual/source/wimax.rst b/doc/manual/source/wimax.rst index c33d531c4..4a6ff7b74 100644 --- a/doc/manual/source/wimax.rst +++ b/doc/manual/source/wimax.rst @@ -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::: diff --git a/doc/modules b/doc/modules index c3c419094..5de8adbaf 100644 --- a/doc/modules +++ b/doc/modules @@ -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 */ diff --git a/doc/tutorial/source/conceptual-overview.rst b/doc/tutorial/source/conceptual-overview.rst index 33fd311d5..06ee0f4a3 100644 --- a/doc/tutorial/source/conceptual-overview.rst +++ b/doc/tutorial/source/conceptual-overview.rst @@ -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. diff --git a/doc/tutorial/source/tracing.rst b/doc/tutorial/source/tracing.rst index 31de42458..c35f1155d 100644 --- a/doc/tutorial/source/tracing.rst +++ b/doc/tutorial/source/tracing.rst @@ -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