diff --git a/doc/manual/source/attributes.rst b/doc/manual/source/attributes.rst index ee2e65557..eeba2744f 100644 --- a/doc/manual/source/attributes.rst +++ b/doc/manual/source/attributes.rst @@ -53,7 +53,7 @@ As introduced in the |ns3| tutorial, |ns3| objects are memory managed by a Smart pointers are used extensively in the |ns3| APIs, to avoid passing references to heap-allocated objects that may cause memory leaks. -For most basic usage (syntax), treat a smart pointer like a regular pointer::: +For most basic usage (syntax), treat a smart pointer like a regular pointer:: Ptr nd = ...; nd->CallSomeFunction (); @@ -67,11 +67,11 @@ lowest-level API, objects of type :cpp:class:`ns3::Object` are not instantiated using ``operator new`` as usual but instead by a templated function called :cpp:func:`CreateObject()`. -A typical way to create such an object is as follows::: +A typical way to create such an object is as follows:: Ptr nd = CreateObject (); -You can think of this as being functionally equivalent to::: +You can think of this as being functionally equivalent to:: WifiNetDevice* nd = new WifiNetDevice (); @@ -102,7 +102,7 @@ Putting all of these concepts together, let's look at a specific example: class :cpp:class:`ns3::Node`. The public header file node.h has a declaration that includes a static GetTypeId -function call::: +function call:: class Node : public Object { @@ -110,7 +110,7 @@ function call::: static TypeId GetTypeId (void); ... -This is defined in the ``node.cc`` file as follows::: +This is defined in the ``node.cc`` file as follows:: TypeId Node::GetTypeId (void) @@ -210,7 +210,7 @@ to them. Consider a class DropTailQueue that has a member variable that is an unsigned integer ``m_maxPackets``; this member variable controls the depth of the queue. -If we look at the declaration of DropTailQueue, we see the following::: +If we look at the declaration of DropTailQueue, we see the following:: class DropTailQueue : public Queue { public: @@ -233,7 +233,7 @@ The above things typically require providing Set() and Get() functions, and some type of global default value. In the |ns3| attribute system, these value definitions and accessor functions -are moved into the TypeId class; e.g.::: +are moved into the TypeId class; e.g.:: NS_OBJECT_ENSURE_REGISTERED (DropTailQueue); @@ -424,11 +424,11 @@ Setting through constructors helper classes +++++++++++++++++++++++++++++++++++++++++++ Arbitrary combinations of attributes can be set and fetched from -the helper and low-level APIs; either from the constructors themselves::: +the helper and low-level APIs; either from the constructors themselves:: Ptr p = CreateObject ("n1", v1, "n2", v2, ...); -or from the higher-level helper APIs, such as::: +or from the higher-level helper APIs, such as:: mobility.SetPositionAllocator ("ns3::GridPositionAllocator", "MinX", DoubleValue (-100.0), @@ -451,7 +451,7 @@ attribute system. Recall that this database is holding objects of many types with a single generic type. Conversions to this type can either be done using an intermediate class (IntegerValue, DoubleValue for "floating point") or via strings. Direct implicit conversion of types to Value is not really practical. -So in the above, users have a choice of using strings or values::: +So in the above, users have a choice of using strings or values:: p->Set ("cwnd", StringValue ("100")); // string-based setter p->Set ("cwnd", IntegerValue (100)); // integer-based setter @@ -488,7 +488,7 @@ variables is executed after an object is constructed. But what if you need the values assigned before the constructor body executes, because you need them in the logic of the constructor? There is a way to do this, used for example in the class :cpp:class:`ns3::ConfigStore`: call ``ObjectBase::ConstructSelf ()`` as -follows::: +follows:: ConfigStore::ConfigStore () { @@ -510,14 +510,14 @@ missed, or to add their own classes to this. Adding an existing internal variable to the metadata system +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ -Consider this variable in class TcpSocket::: +Consider this variable in class TcpSocket:: uint32_t m_cWnd; // Congestion window Suppose that someone working with TCP wanted to get or set the value of that variable using the metadata system. If it were not already provided by |ns3|, the user could declare the following addition in the runtime metadata system (to -the TypeId declaration for TcpSocket)::: +the TypeId declaration for TcpSocket):: .AddAttribute ("Congestion window", "Tcp congestion window (bytes)", @@ -537,7 +537,7 @@ Adding a new TypeId Here, we discuss the impact on a user who wants to add a new class to |ns3|; what additional things must be done to hook it into this system. -We've already introduced what a TypeId definition looks like::: +We've already introduced what a TypeId definition looks like:: TypeId RandomWalk2dMobilityModel::GetTypeId (void) @@ -562,7 +562,7 @@ We've already introduced what a TypeId definition looks like::: } The declaration for this in the class declaration is one-line public member -method::: +method:: public: static TypeId GetTypeId (void); @@ -606,7 +606,7 @@ Header file }; One macro call and two operators, must be added below the class declaration in -order to turn a Rectangle into a value usable by the ``Attribute`` system::: +order to turn a Rectangle into a value usable by the ``Attribute`` system:: std::ostream &operator << (std::ostream &os, const Rectangle &rectangle); std::istream &operator >> (std::istream &is, Rectangle &rectangle); @@ -616,7 +616,7 @@ order to turn a Rectangle into a value usable by the ``Attribute`` system::: Implementation file +++++++++++++++++++ -In the class definition (``.cc`` file), the code looks like this::: +In the class definition (``.cc`` file), the code looks like this:: ATTRIBUTE_HELPER_CPP (Rectangle); @@ -660,12 +660,12 @@ and loaded into a future simulation. This feature is known as the |ns3| ConfigStore. We can explore this system by using an example from ``src/config-store/examples/config-store-save.cc``. -First, all users must include the following statement::: +First, all users must include the following statement:: #include "ns3/config-store-module.h" Next, this program adds a sample object A to show how the system -is extended::: +is extended:: class A : public Object { @@ -686,7 +686,7 @@ is extended::: NS_OBJECT_ENSURE_REGISTERED (A); Next, we use the Config subsystem to override the defaults in a couple of -ways::: +ways:: Config::SetDefault ("ns3::A::TestInt16", IntegerValue (-5)); @@ -703,7 +703,7 @@ The next statement is necessary to make sure that (one of) the objects created is rooted in the configuration namespace as an object instance. This normally happens when you aggregate objects to ns3::Node or ns3::Channel but here, since we are working at the core level, we need to create a -new root namespace object::: +new root namespace object:: Config::RegisterRootNamespaceObject (a2_obj); @@ -720,7 +720,7 @@ There are three attributes that govern the behavior of the ConfigStore: "Mode", (default "RawText") governs whether the ConfigStore format is Xml or RawText format. -The example shows::: +The example shows:: Config::SetDefault ("ns3::ConfigStore::Filename", StringValue ("output-attributes.xml")); Config::SetDefault ("ns3::ConfigStore::FileFormat", StringValue ("Xml")); @@ -895,7 +895,7 @@ version is installed and: is rerun. Usage is almost the same as the non-GTK-based version, but there -are no ConfigStore attributes involved::: +are no ConfigStore attributes involved:: // Invoke just before entering Simulator::Run () GtkConfigStore config; diff --git a/doc/manual/source/new-models.rst b/doc/manual/source/new-models.rst index b875d0dfe..20efa10f6 100644 --- a/doc/manual/source/new-models.rst +++ b/doc/manual/source/new-models.rst @@ -44,7 +44,7 @@ return value of this function is a boolean that tells the caller whether any corruption occurred. Note that depending on the error model, the packet data buffer may or may not be corrupted. Let's call this function "IsCorrupt()". -So far, in our design, we have::: +So far, in our design, we have:: class ErrorModel { @@ -95,7 +95,7 @@ a user to force errors on otherwise successful packet transmissions, at the NetDevice level. After some thinking and looking at existing |ns2| code, here is a sample API of -a base class and first subclass that could be posted for initial review::: +a base class and first subclass that could be posted for initial review:: class ErrorModel { @@ -217,7 +217,7 @@ an |ns3| namespace block in both the cc and h file.:: } At this point, we have some skeletal files in which we can start defining -our new classes. The header file looks like this::: +our new classes. The header file looks like this:: #ifndef ERROR_MODEL_H #define ERROR_MODEL_H @@ -227,7 +227,7 @@ our new classes. The header file looks like this::: } // namespace ns3 #endif -while the ``error-model.cc`` file simply looks like this::: +while the ``error-model.cc`` file simply looks like this:: #include "error-model.h" @@ -541,7 +541,7 @@ We declare BasicErrorModel to be a subclass of ErrorModel as follows,:: } and configure the subclass GetTypeId function by setting a unique TypeId string -and setting the Parent to ErrorModel::: +and setting the Parent to ErrorModel:: TypeId RateErrorModel::GetTypeId (void) { diff --git a/doc/manual/source/object-model.rst b/doc/manual/source/object-model.rst index c5879385d..65934a7dc 100644 --- a/doc/manual/source/object-model.rst +++ b/doc/manual/source/object-model.rst @@ -27,7 +27,7 @@ Object-oriented behavior C++ objects, in general, provide common object-oriented capabilities (abstraction, encapsulation, inheritance, and polymorphism) that are part of classic object-oriented design. |ns3| objects make use of these -properties; for instance::: +properties; for instance:: class Address { @@ -130,7 +130,7 @@ holds true for |ns3| also, but some objects in the system have some additional frameworks available. Specifically, reference counted objects are usually allocated using a templated Create or CreateObject method, as follows. -For objects deriving from class :cpp:class:`Object`::: +For objects deriving from class :cpp:class:`Object`:: Ptr device = CreateObject (); @@ -139,7 +139,7 @@ Please do not create such objects using ``operator new``; create them using For objects deriving from class :cpp:class:`SimpleRefCount`, or other objects that support usage of the smart pointer class, a templated helper function is -available and recommended to be used::: +available and recommended to be used:: Ptr b = Create (); @@ -218,7 +218,7 @@ Consider a node pointer ``m_node`` that points to a Node object that has an implementation of IPv4 previously aggregated to it. The client code wishes to configure a default route. To do so, it must access an object within the node that has an interface to the IP forwarding configuration. It performs the -following::: +following:: Ptr ipv4 = m_node->GetObject (); @@ -281,7 +281,7 @@ to the subclass API?" The answer to this is that in many situations, both techniques will work. |ns3| provides a templated function for making the syntax of Object -dynamic casting much more user friendly::: +dynamic casting much more user friendly:: template Ptr diff --git a/doc/manual/source/tracing.rst b/doc/manual/source/tracing.rst index 24aa2ac50..fbced1723 100644 --- a/doc/manual/source/tracing.rst +++ b/doc/manual/source/tracing.rst @@ -244,7 +244,7 @@ provided. The first thing to do is to read the path backward. The last segment of the path must be an ``Attribute`` of an ``Object``. In fact, if you had a pointer to the ``Object`` that has the "CongestionWindow" ``Attribute`` handy (call it -``theObject``), you could write this just like the previous example::: +``theObject``), you could write this just like the previous example:: void CwndTracer (uint32_t oldval, uint32_t newval) {} @@ -314,7 +314,7 @@ different trace events and writing them to files. In previous sections, primarily "Building Topologies," we have seen several varieties of the trace helper methods designed for use inside other (device) helpers. -Perhaps you will recall seeing some of these variations::: +Perhaps you will recall seeing some of these variations:: pointToPoint.EnablePcapAll ("second"); pointToPoint.EnablePcap ("second", p2pNodes.Get (0)->GetId (), 0); @@ -509,7 +509,7 @@ enable pcap tracing on a single device. For example, in order to arrange for a device helper to create a single promiscuous pcap capture file of a specific name (``my-pcap-file.pcap``) on a -given device, one could::: +given device, one could:: Ptr nd; ... @@ -600,7 +600,7 @@ suffix ".tr" instead of ".pcap". If you want to enable ascii tracing on more than one net device and have all traces sent to a single file, you can do that as well by using an object to -refer to a single file::: +refer to a single file:: Ptr nd1; Ptr nd2; @@ -632,7 +632,7 @@ belong to exactly one ``Node``. For example,:: This would result in two files named ``prefix-client-eth0.tr`` and ``prefix-server-eth0.tr`` with traces for each device in the respective trace file. Since all of the EnableAscii functions are overloaded to take a stream -wrapper, you can use that form as well::: +wrapper, you can use that form as well:: Names::Add ("client" ...); Names::Add ("client/eth0" ...); @@ -660,7 +660,7 @@ since the found net device must belong to exactly one ``Node``. For example,:: This would result in a number of ascii trace files being created, each of which follows the --.tr convention. Combining all of the -traces into a single file is accomplished similarly to the examples above::: +traces into a single file is accomplished similarly to the examples above:: NetDeviceContainer d = ...; ... @@ -768,7 +768,7 @@ and ``NetDevice``- centric versions of the device versions. Instead of ``Node`` and ``NetDevice`` pair constraints, we use protocol and interface constraints. -Note that just like in the device version, there are six methods::: +Note that just like in the device version, there are six methods:: void EnablePcapIpv4 (std::string prefix, Ptr ipv4, uint32_t interface); void EnablePcapIpv4 (std::string prefix, std::string ipv4Name, uint32_t interface); @@ -948,7 +948,7 @@ suffix ".tr" instead of ".pcap". If you want to enable ascii tracing on more than one interface and have all traces sent to a single file, you can do that as well by using an object to refer to a single file. We have already something similar to this in the "cwnd" -example above::: +example above:: Ptr protocol1 = node1->GetObject (); Ptr protocol2 = node2->GetObject (); @@ -978,7 +978,7 @@ between protocol instances and nodes, For example,:: This would result in two files named "prefix-nnode1Ipv4-i1.tr" and "prefix-nnode2Ipv4-i1.tr" with traces for each interface in the respective trace file. Since all of the EnableAscii functions are overloaded to take a -stream wrapper, you can use that form as well::: +stream wrapper, you can use that form as well:: Names::Add ("node1Ipv4" ...); Names::Add ("node2Ipv4" ...); @@ -1011,7 +1011,7 @@ one-to-one correspondence between each protocol and its node. For example,:: This would result in a number of ascii trace files being created, each of which follows the -n-i.tr convention. Combining all of the -traces into a single file is accomplished similarly to the examples above::: +traces into a single file is accomplished similarly to the examples above:: NodeContainer nodes; ... diff --git a/doc/manual/source/troubleshoot.rst b/doc/manual/source/troubleshoot.rst index f704a15cb..c198eb5f9 100644 --- a/doc/manual/source/troubleshoot.rst +++ b/doc/manual/source/troubleshoot.rst @@ -21,7 +21,7 @@ Sometimes, errors can occur with a program after a successful build. These are run-time errors, and can commonly occur when memory is corrupted or pointer values are unexpectedly null. -Here is an example of what might occur::: +Here is an example of what might occur:: $ ./waf --run tcp-point-to-point Entering directory '/home/tomh/ns-3-nsc/build' diff --git a/doc/models/Makefile b/doc/models/Makefile index b5b92830a..1c8e51ceb 100644 --- a/doc/models/Makefile +++ b/doc/models/Makefile @@ -34,6 +34,7 @@ SOURCES = \ $(SRC)/csma/doc/csma.rst \ $(SRC)/dsdv/doc/dsdv.rst \ $(SRC)/dsr/doc/dsr.rst \ + $(SRC)/emu/doc/emu.rst \ $(SRC)/mpi/doc/distributed.rst \ $(SRC)/energy/doc/energy.rst \ $(SRC)/fd-net-device/doc/fd-net-device.rst \ @@ -66,6 +67,14 @@ SOURCES = \ $(SRC)/uan/doc/uan.rst \ $(SRC)/topology-read/doc/topology.rst \ $(SRC)/spectrum/doc/spectrum.rst \ + $(SRC)/stats/doc/adaptor.rst \ + $(SRC)/stats/doc/aggregator.rst \ + $(SRC)/stats/doc/collector.rst \ + $(SRC)/stats/doc/data-collection-helpers.rst \ + $(SRC)/stats/doc/data-collection-overview.rst \ + $(SRC)/stats/doc/data-collection.rst \ + $(SRC)/stats/doc/probe.rst \ + $(SRC)/stats/doc/scope-and-limitations.rst \ $(SRC)/stats/doc/statistics.rst \ $(SRC)/netanim/doc/animation.rst \ $(SRC)/flow-monitor/doc/flow-monitor.rst \ @@ -195,6 +204,13 @@ SOURCEFIGS = \ $(SRC)/uan/doc/auvmobility-classes.dia \ $(SRC)/stats/doc/Stat-framework-arch.png \ $(SRC)/stats/doc/Wifi-default.png \ + $(SRC)/stats/doc/dcf-overview.dia \ + $(SRC)/stats/doc/dcf-overview-with-aggregation.dia \ + $(SRC)/stats/doc/file-example.png \ + $(SRC)/stats/doc/gnuplot-aggregator.png \ + $(SRC)/stats/doc/gnuplot-example.png \ + $(SRC)/stats/doc/gnuplot-helper-example.png \ + $(SRC)/stats/doc/seventh-packet-byte-count.png \ $(SRC)/netanim/doc/figures/Dumbbell.png \ $(SRC)/netanim/doc/figures/Dumbbell.pdf \ $(SRC)/netanim/doc/figures/PacketStatistics.png \ @@ -235,6 +251,8 @@ IMAGES_EPS = \ $(FIGURES)/WifiArchitecture.eps \ $(FIGURES)/snir.eps \ $(FIGURES)/WimaxArchitecture.eps \ + $(FIGURES)/dcf-overview.eps \ + $(FIGURES)/dcf-overview-with-aggregation.eps \ $(FIGURES)/epc-ctrl-arch.eps \ $(FIGURES)/epc-data-flow-dl.eps \ $(FIGURES)/epc-data-flow-ul.eps \ diff --git a/doc/models/source/emulation-overview.rst b/doc/models/source/emulation-overview.rst index 64a6a3809..1b8214ca2 100644 --- a/doc/models/source/emulation-overview.rst +++ b/doc/models/source/emulation-overview.rst @@ -83,5 +83,6 @@ simulated |ns3| networks. .. toctree:: + emu fd-net-device tap diff --git a/doc/models/source/index.rst b/doc/models/source/index.rst index d2e68fdf0..a1bd49675 100644 --- a/doc/models/source/index.rst +++ b/doc/models/source/index.rst @@ -26,6 +26,7 @@ This document is written in `reStructuredText TRANSMITTING -> PROPAGATING -> IDLE @@ -207,7 +207,7 @@ work in a similar way, and their use is seen in many of our example programs. The conceptual model of interest is that of a bare computer "husk" into which you plug net devices. The bare computers are created using a ``NodeContainer`` helper. You just ask this helper to create as many computers (we call them -``Nodes``) as you need on your network::: +``Nodes``) as you need on your network:: NodeContainer csmaNodes; csmaNodes.Create (nCsmaNodes); diff --git a/src/emu/doc/emu.rst b/src/emu/doc/emu.rst index cd436636c..6a9f15602 100644 --- a/src/emu/doc/emu.rst +++ b/src/emu/doc/emu.rst @@ -59,7 +59,7 @@ Usage Any mixing of |ns3| objects with real objects will typically require that |ns3| compute checksums in its protocols. By default, checksums are not computed by |ns3|. To enable checksums (e.g. UDP, TCP, IP), users must set -the attribute ``ChecksumEnabled`` to true, such as follows::: +the attribute ``ChecksumEnabled`` to true, such as follows:: GlobalValue::Bind ("ChecksumEnabled", BooleanValue (true)); @@ -141,7 +141,7 @@ similarly to the snippet above.:: The ``Emu`` net device and helper provide access to ASCII and pcap tracing functionality just as other |ns3| net devices to. You enable tracing similarly -to these other net devices::: +to these other net devices:: EmuHelper::EnablePcapAll ("emu-udp-echo-client"); @@ -176,7 +176,7 @@ the device using the "Stop" attribute. Once the (promiscuous mode) socket is created, we bind it to an interface name also provided as an attribute ("DeviceName") that is stored internally as -``m_deviceName``::: +``m_deviceName``:: struct ifreq ifr; bzero (&ifr, sizeof(ifr)); diff --git a/src/internet/doc/internet-stack.rst b/src/internet/doc/internet-stack.rst index 4ab3f86b4..d6c47b8ba 100644 --- a/src/internet/doc/internet-stack.rst +++ b/src/internet/doc/internet-stack.rst @@ -17,7 +17,7 @@ IPv6, Neighbor Discovery, and other related protocols. Internet Nodes are not subclasses of class Node; they are simply Nodes that have had a bunch of IP-related objects aggregated to them. They can be put together by hand, or via a helper function :cpp:func:`InternetStackHelper::Install ()` -which does the following to all nodes passed in as arguments::: +which does the following to all nodes passed in as arguments:: void InternetStackHelper::Install (Ptr node) const @@ -77,7 +77,7 @@ Where multiple implementations exist in |ns3| (TCP, IP routing), these objects are added by a factory object (TCP) or by a routing helper (m_routing). Note that the routing protocol is configured and set outside this -function. By default, the following protocols are added::: +function. By default, the following protocols are added:: void InternetStackHelper::Initialize () { @@ -111,7 +111,7 @@ including IPv4, IPv6, ARP and so on. The class 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 ()``::: +In class Ipv4L3Protocol, one method described below is ``Receive ()``:: /** * Lower layer calls this method after calling L3Demux::Lookup @@ -127,7 +127,7 @@ First, note that the ``Receive ()`` function has a matching signature to the ReceiveCallback in the class :cpp:class:`Node`. This function pointer is inserted into the Node's protocol handler when ``AddInterface ()`` is called. The actual registration is done -with a statement such as follows::: +with a statement such as follows:: RegisterProtocolHandler ( MakeCallback (&Ipv4Protocol::Receive, ipv4), Ipv4L3Protocol::PROT_NUMBER, 0); @@ -135,7 +135,7 @@ with a statement such as follows::: The Ipv4L3Protocol object is aggregated to the Node; there is only one such Ipv4L3Protocol object. Higher-layer protocols that have a packet to send down to the Ipv4L3Protocol object can call ``GetObject ()`` to obtain a -pointer, as follows::: +pointer, as follows:: Ptr ipv4 = m_node->GetObject (); if (ipv4 != 0) @@ -147,7 +147,7 @@ This class nicely demonstrates two techniques we exploit in |ns3| to bind objects together: callbacks, and object aggregation. Once IPv4 routing has determined that a packet is for the local node, it -forwards it up the stack. This is done with the following function::: +forwards it up the stack. This is done with the following function:: void Ipv4L3Protocol::LocalDeliver (Ptr packet, Ipv4Header const&ip, uint32_t iif) @@ -169,7 +169,7 @@ common mistake is to forget the effects of local queues when sending packets, e. queue. This can be particularly puzzling when sending jumbo packets or packet bursts using UDP. The ARP cache pending queue is limited (3 datagrams) and IP packets might be fragmented, easily overfilling the ARP cache queue size. In those cases it is useful to increase the ARP cache -pending size to a proper value, e.g.::: +pending size to a proper value, e.g.:: Config::SetDefault ("ns3::ArpCache::PendingQueueSize", UintegerValue (MAX_BURST_SIZE/L2MTU*3)); @@ -188,7 +188,7 @@ together. In summary, each transport protocol implementation is a socket factory. An application that needs a new socket For instance, to create a UDP socket, an application would use a code snippet -such as the following::: +such as the following:: Ptr udpSocketFactory = GetNode ()->GetObject (); Ptr m_socket = socketFactory->CreateSocket (); @@ -226,14 +226,14 @@ some type of I/O (e.g., blocking, non-blocking, asynchronous, ...). |ns3| implements an asynchronous model for socket I/O; the application sets a callback to be notified of received data ready to be read, and the callback is invoked by the transport protocol when data is available. -This callback is specified as follows::: +This callback is specified as follows:: void Socket::SetRecvCallback (Callback, Ptr, const Address&> receivedData); The data being received is conveyed in the Packet data buffer. An example -usage is in class :cpp:class:`PacketSink`::: +usage is in class :cpp:class:`PacketSink`:: m_socket->SetRecvCallback (MakeCallback(&PacketSink::HandleRead, this)); diff --git a/src/internet/doc/routing-overview.rst b/src/internet/doc/routing-overview.rst index 32a1bf936..119a1a7e2 100644 --- a/src/internet/doc/routing-overview.rst +++ b/src/internet/doc/routing-overview.rst @@ -111,14 +111,14 @@ over routes found by global routing). Global Unicast Routing API ++++++++++++++++++++++++++ -The public API is very minimal. User scripts include the following::: +The public API is very minimal. User scripts include the following:: #include "ns3/internet-module.h" If the default InternetStackHelper is used, then an instance of global routing will be aggregated to each node. After IP addresses are configured, the following function call will cause all of the nodes that have an Ipv4 interface -to receive forwarding tables entered automatically by the GlobalRouteManager::: +to receive forwarding tables entered automatically by the GlobalRouteManager:: Ipv4GlobalRoutingHelper::PopulateRoutingTables (); @@ -127,7 +127,7 @@ wireless effects into account. For wireless, we recommend OLSR dynamic routing described below. It is possible to call this function again in the midst of a simulation using -the following additional public function::: +the following additional public function:: Ipv4GlobalRoutingHelper::RecomputeRoutingTables (); @@ -135,7 +135,7 @@ which flushes the old tables, queries the nodes for new interface information, and rebuilds the routes. For instance, this scheduling call will cause the tables to be rebuilt -at time 5 seconds::: +at time 5 seconds:: Simulator::Schedule (Seconds (5), &Ipv4GlobalRoutingHelper::RecomputeRoutingTables); @@ -195,7 +195,7 @@ same shared channel is reachable from every other node (i.e. it will be treated like a broadcast CSMA link). The GlobalRouteManager first walks the list of nodes and aggregates -a GlobalRouter interface to each one as follows::: +a GlobalRouter interface to each one as follows:: typedef std::vector < Ptr >::iterator Iterator; for (Iterator i = NodeList::Begin (); i != NodeList::End (); i++) @@ -257,7 +257,7 @@ Ipv4ListRouting::AddRoutingProtocol ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Class Ipv4ListRouting provides a pure virtual function declaration for the -method that allows one to add a routing protocol::: +method that allows one to add a routing protocol:: void AddRoutingProtocol (Ptr routingProtocol, int16_t priority); @@ -272,7 +272,7 @@ Ipv4StaticRoutingImpl object at priority zero. Internally, a list of Ipv4RoutingProtocols is stored, and and the routing protocols are each consulted in decreasing order of priority to see whether a match is found. Therefore, if you want your Ipv4RoutingProtocol to have priority lower than the static -routing, insert it with priority less than 0; e.g.::: +routing, insert it with priority less than 0; e.g.:: Ptr myRoutingProto = CreateObject (); listRoutingPtr->AddRoutingProtocol (myRoutingProto, -10); @@ -335,7 +335,7 @@ Multicast routing ***************** The following function is used to add a static multicast route -to a node::: +to a node:: void Ipv4StaticRouting::AddMulticastRoute (Ipv4Address origin, @@ -371,7 +371,7 @@ interfaces. Compare this to the actual default multicast address that is limited to specifying a single output interface for compatibility with existing functionality in other systems. -Another command sets the default multicast route::: +Another command sets the default multicast route:: void Ipv4StaticRouting::SetDefaultMulticastRoute (uint32_t outputInterface); @@ -392,7 +392,7 @@ irrespective of origin or multicast group if another specific route is not found. Finally, a number of additional functions are provided to fetch and remove -multicast routes::: +multicast routes:: uint32_t GetNMulticastRoutes (void) const; diff --git a/src/internet/doc/tcp.rst b/src/internet/doc/tcp.rst index 94b576c09..54dab4d77 100644 --- a/src/internet/doc/tcp.rst +++ b/src/internet/doc/tcp.rst @@ -73,7 +73,7 @@ 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/applications/helper`` and -``src/network/helper``, here is how one would create a TCP receiver::: +``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; @@ -84,7 +84,7 @@ Using the helper functions defined in ``src/applications/helper`` and sinkApp.Stop (Seconds (10.0)); Similarly, the below snippet configures OnOffApplication traffic source to use -TCP::: +TCP:: // Create the OnOff applications to send TCP to the server OnOffHelper clientHelper ("ns3::TcpSocketFactory", Address ()); @@ -106,7 +106,7 @@ settable attribute. To set the default socket type before any internet stack-related objects are created, one may put the following statement at the top of the simulation -program::: +program:: Config::SetDefault ("ns3::TcpL4Protocol::SocketType", StringValue ("ns3::TcpTahoe")); @@ -119,7 +119,7 @@ socket type must be done by twiddling the attribute associated with the underlying TcpL4Protocol object. The easiest way to get at this would be through the attribute configuration system. In the below example, the Node container "n0n1" is accessed -to get the zeroth element, and a socket is created on this node::: +to get the zeroth element, and a socket is created on this node:: // Create and bind the socket... TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe"); @@ -130,7 +130,7 @@ to get the zeroth element, and a socket is created on this node::: Above, the "*" wild card for node number is passed to the attribute configuration system, so that all future sockets on all nodes are set to Tahoe, not just on node 'n0n1.Get (0)'. If one wants to limit it to just -the specified node, one would have to do something like::: +the specified node, one would have to do something like:: // Create and bind the socket... TypeId tid = TypeId::LookupByName ("ns3::TcpTahoe"); @@ -233,7 +233,7 @@ which can be examined by tcpdump or wireshark. Let's look at the ``examples/tcp/tcp-nsc-zoo.cc`` file for some typical usage. How does it differ from using native |ns3| TCP? There is one main configuration line, when using NSC and the |ns3| helper API, that needs to be -set::: +set:: InternetStackHelper internetStack; @@ -271,7 +271,7 @@ sockets, as described above and documented in `Doxygen Additionally, NSC TCP exports a lot of configuration variables into the |ns3| attributes system, via a `sysctl `_-like interface. In the ``examples/tcp/tcp-nsc-zoo`` example, you -can see the following configuration::: +can see the following configuration:: // this disables TCP SACK, wscale and timestamps on node 1 (the attributes diff --git a/src/mpi/doc/distributed.rst b/src/mpi/doc/distributed.rst index c613ea980..36d10c3ff 100644 --- a/src/mpi/doc/distributed.rst +++ b/src/mpi/doc/distributed.rst @@ -132,23 +132,23 @@ retype them when a new shell is opened. Building and Running Examples +++++++++++++++++++++++++++++ -If you already built |ns3| without MPI enabled, you must re-build::: +If you already built |ns3| without MPI enabled, you must re-build:: $ ./waf distclean -Configure |ns3| with the --enable-mpi option::: +Configure |ns3| with the --enable-mpi option:: $ ./waf -d debug configure --enable-examples --enable-tests --enable-mpi Ensure that MPI is enabled by checking the optional features shown from the output of configure. -Next, build |ns3|::: +Next, build |ns3|:: $ ./waf After building |ns3| with mpi enabled, the example programs are now ready to run -with mpirun. Here are a few examples (from the root |ns3| directory)::: +with mpirun. Here are a few examples (from the root |ns3| directory):: $ mpirun -np 2 ./waf --run simple-distributed $ mpirun -np 4 -machinefile mpihosts ./waf --run 'nms-udp-nix --LAN=2 --CN=4 --nix=1' @@ -167,7 +167,7 @@ exist (in this case mpihosts). This can simply contain something like: Or if you have a cluster of machines, you can name them. NOTE: Some users have experienced issues using mpirun and waf together. An -alternative way to run distributed examples is shown below::: +alternative way to run distributed examples is shown below:: $ ./waf shell $ cd build/debug @@ -184,14 +184,14 @@ be divided, and installing applications only on the LP associated with the target node. Assigning system ids to nodes is simple and can be handled two different ways. -First, a NodeContainer can be used to create the nodes and assign system ids::: +First, a NodeContainer can be used to create the nodes and assign system ids:: NodeContainer nodes; nodes.Create (5, 1); // Creates 5 nodes with system id 1. Alternatively, nodes can be created individually, assigned system ids, and added to a NodeContainer. This is useful if a NodeContainer holds nodes with different -system ids::: +system ids:: NodeContainer nodes; Ptr node1 = CreateObject (0); // Create node1 with system id 0 @@ -219,7 +219,7 @@ simulator until it reaches nodes specific to that simulator. The easiest way to keep track of different traces is to just name the trace files or pcaps differently, based on the system id of the simulator. For example, something like this should work well, assuming all of these local variables were -previously defined::: +previously defined:: if (MpiInterface::GetSystemId () == 0) { diff --git a/src/network/doc/packets.rst b/src/network/doc/packets.rst index 5710f93a3..4ad2b4e32 100644 --- a/src/network/doc/packets.rst +++ b/src/network/doc/packets.rst @@ -162,7 +162,7 @@ The following command will create a new packet with a new unique Id.:: Ptr pkt = Create (); What is the Uid (unique Id)? It is an internal id that the system uses to -identify packets. It can be fetched via the following method::: +identify packets. It can be fetched via the following method:: uint32_t uid = pkt->GetUid (); @@ -180,14 +180,14 @@ payloads that do not actually require a memory allocation (i.e., the packet may behave, when delays such as serialization or transmission delays are computed, to have a certain number of payload bytes, but the bytes will only be allocated on-demand when needed). The command to do this is, when the packet is -created::: +created:: Ptr pkt = Create (N); where N is a positive integer. The packet now has a size of N bytes, which can be verified by the GetSize() -method::: +method:: /** * \returns the size in bytes of the packet (including the zero-filled @@ -197,11 +197,11 @@ method::: You can also initialize a packet with a character buffer. The input data is copied and the input buffer is untouched. The constructor -applied is::: +applied is:: Packet (uint8_t const *buffer, uint32_t size); -Here is an example::: +Here is an example:: Ptr pkt1 = Create (reinterpret_cast ("hello"), 5); @@ -422,14 +422,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/model/udp-socket-impl.cc``::: +code in ``src/internet/model/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/model/ipv4-l3-protocol.cc``)::: +This tag is read at the IP layer, then stripped (``src/internet/model/ipv4-l3-protocol.cc``):: uint8_t ttl = m_defaultTtl; SocketIpTtlTag tag; @@ -444,7 +444,7 @@ Fragmentation and concatenation Packets may be fragmented or merged together. For example, to fragment a packet ``p`` of 90 bytes into two packets, one containing the first 10 bytes and the -other containing the remaining 80, one may call the following code::: +other containing the remaining 80, one may call the following code:: Ptr frag0 = p->CreateFragment (0, 10); Ptr frag1 = p->CreateFragment (10, 90); @@ -452,7 +452,7 @@ other containing the remaining 80, one may call the following code::: As discussed above, the packet tags from ``p`` will follow to both packet fragments, and the byte tags will follow the byte ranges as needed. -Now, to put them back together::: +Now, to put them back together:: frag0->AddAtEnd (frag1); @@ -481,7 +481,7 @@ present at the front of the packet. These errors will be detected and will abort the program. To enable this operation, users will typically insert one or both of these -statements at the beginning of their programs::: +statements at the beginning of their programs:: Packet::EnablePrinting (); Packet::EnableChecking (); @@ -497,7 +497,7 @@ Implementation details Private member variables ++++++++++++++++++++++++ -A Packet object's interface provides access to some private data::: +A Packet object's interface provides access to some private data:: Buffer m_buffer; ByteTagList m_byteTagList; @@ -602,7 +602,7 @@ copying the TagData head pointer and incrementing its reference count. Tags are found by the unique mapping between the Tag type and its underlying id. This is why at most one instance of any Tag can be stored in a packet. The mapping between Tag type and -underlying id is performed by a registration as follows::: +underlying id is performed by a registration as follows:: /* A sample Tag implementation */ diff --git a/src/network/doc/sockets-api.rst b/src/network/doc/sockets-api.rst index 2f28f7d5c..28b5ffff0 100644 --- a/src/network/doc/sockets-api.rst +++ b/src/network/doc/sockets-api.rst @@ -128,7 +128,7 @@ sending of more data until a function registered at the :cpp:func:`ns3::Socket::SetSendCallback` callback is invoked. An application can also ask the socket how much space is available by calling :cpp:func:`ns3::Socket::GetTxAvailable`. A typical sequence -of events for sending data (ignoring connection setup) might be::: +of events for sending data (ignoring connection setup) might be:: SetSendCallback (MakeCallback(&HandleSendCallback)); Send (); diff --git a/src/point-to-point/doc/point-to-point.rst b/src/point-to-point/doc/point-to-point.rst index 70196ead2..712b90530 100644 --- a/src/point-to-point/doc/point-to-point.rst +++ b/src/point-to-point/doc/point-to-point.rst @@ -77,7 +77,7 @@ example programs and is also covered in the |ns3| tutorial. The conceptual model of interest is that of a bare computer "husk" into which you plug net devices. The bare computers are created using a ``NodeContainer`` helper. You just ask this helper to create as many computers (we call them -``Nodes``) as you need on your network::: +``Nodes``) as you need on your network:: NodeContainer nodes; nodes.Create (2); diff --git a/src/stats/doc/data-collection.rst b/src/stats/doc/data-collection.rst index 3d4537aba..2be8e2d2a 100644 --- a/src/stats/doc/data-collection.rst +++ b/src/stats/doc/data-collection.rst @@ -32,5 +32,6 @@ low-level coding examples. collector.rst aggregator.rst adaptor.rst + statistics.rst scope-and-limitations.rst diff --git a/src/wifi/doc/wifi.rst b/src/wifi/doc/wifi.rst index a939171e0..5d5ddda9c 100644 --- a/src/wifi/doc/wifi.rst +++ b/src/wifi/doc/wifi.rst @@ -150,7 +150,7 @@ propagation delay equal to a constant, the speed of light, and a propagation loss based on a log distance model with a reference loss of 46.6777 dB at reference distance of 1m. -Users will typically type code such as::: +Users will typically type code such as:: YansWifiChannelHelper wifiChannelHelper = YansWifiChannelHelper::Default (); Ptr wifiChannel = wifiChannelHelper.Create (); @@ -175,7 +175,7 @@ the ``YansWifiPhyHelper`` will do the work. The YansWifiPhyHelper class configures an object factory to create instances of a ``YansWifiPhy`` and adds some other objects to it, including possibly a supplemental ErrorRateModel and a pointer to a MobilityModel. The user code is -typically::: +typically:: YansWifiPhyHelper wifiPhyHelper = YansWifiPhyHelper::Default (); wifiPhyHelper.SetChannel (wifiChannel); @@ -200,7 +200,7 @@ instances that do not have 802.11e/WMM-style QoS support enabled. For example the following user code configures a non-QoS MAC that will be a non-AP STA in an infrastructure network where the AP has -SSID ``ns-3-ssid``::: +SSID ``ns-3-ssid``:: NqosWifiMacHelper wifiMacHelper = NqosWifiMacHelper::Default (); Ssid ssid = Ssid ("ns-3-ssid"); @@ -218,7 +218,7 @@ To create MAC instances with QoS support enabled, mechanism should be used) and inactivity timeout. The following code shows an example use of ``ns3::QosWifiMacHelper`` to -create an AP with QoS enabled, aggregation on AC_VO, and Block Ack on AC_BE::: +create an AP with QoS enabled, aggregation on AC_VO, and Block Ack on AC_BE:: QosWifiMacHelper wifiMacHelper = QosWifiMacHelper::Default (); wifiMacHelper.SetType ("ns3::ApWifiMac", @@ -239,7 +239,7 @@ supports creation of MAC instances that have 802.11n-style High throughput (Ht) For example the following user code configures a HT MAC that will be a non-AP STA in an infrastructure network where the AP has -SSID ``ns-3-ssid``::: +SSID ``ns-3-ssid``:: HtWifiMacHelper wifiMacHelper = HtWifiMacHelper::Default (); Ssid ssid = Ssid ("ns-3-ssid"); @@ -253,14 +253,14 @@ WifiHelper ++++++++++ We're now ready to create WifiNetDevices. First, let's create -a WifiHelper with default settings::: +a WifiHelper with default settings:: WifiHelper wifiHelper = WifiHelper::Default (); What does this do? It sets the RemoteStationManager to ``ns3::ArfWifiManager``. Now, let's use the wifiPhyHelper and wifiMacHelper created above to install WifiNetDevices -on a set of nodes in a NodeContainer "c"::: +on a set of nodes in a NodeContainer "c":: NetDeviceContainer wifiContainer = WifiHelper::Install (wifiPhyHelper, wifiMacHelper, c); diff --git a/src/wimax/doc/wimax.rst b/src/wimax/doc/wimax.rst index d24795792..2f811420b 100644 --- a/src/wimax/doc/wimax.rst +++ b/src/wimax/doc/wimax.rst @@ -79,7 +79,7 @@ attributes of the model. 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::: +shows how to set up the model:: switch (schedType) { @@ -118,7 +118,7 @@ type, the physical layer type, and the device type. Different variants of ``Install`` are available; for instance, the example ``src/wimax/examples/wimax-multicast.cc`` shows how to specify a non-default channel -or propagation model::: +or propagation model:: channel = CreateObject (); channel->SetPropagationModel (SimpleOfdmWimaxChannel::COST231_PROPAGATION); @@ -141,7 +141,7 @@ 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 ``src/wimax/examples/wimax-multicast.cc`` shows how this is -configured from a helper level::: +configured from a helper level:: ServiceFlow MulticastServiceFlow = wimax.CreateServiceFlow (ServiceFlow::SF_DIRECTION_DOWN, ServiceFlow::SF_TYPE_UGS, @@ -179,7 +179,7 @@ Wimax Tracing existing trace sources, or to define and export new ones. Many |ns3| users use the built-in Pcap or Ascii tracing, and the -WimaxHelper has similar APIs::: +WimaxHelper has similar APIs:: AsciiTraceHelper ascii; WimaxHelper wimax;