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

Remove extra ':'s

Browse Source
This commit is contained in:
Peter D. Barnes, Jr.
2013-11-14 16:57:49 -08:00
parent 1c3e6149ab
commit cce3b82113
21 changed files with 137 additions and 116 deletions
Download Patch File Download Diff File Expand all files Collapse all files

46
doc/manual/source/attributes.rst
View File

@@ -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<WifiNetDevice> 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<WifiNetDevice> nd = CreateObject<WifiNetDevice> ();
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<Object> p = CreateObject<MyNewObject> ("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;

10
doc/manual/source/new-models.rst
View File

@@ -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)
{

10
doc/manual/source/object-model.rst
View File

@@ -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<WifiNetDevice> device = CreateObject<WifiNetDevice> ();
@@ -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> b = Create<B> ();
@@ -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> ipv4 = m_node->GetObject<Ipv4> ();
@@ -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 <typename T1, typename T2>
Ptr<T1>

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

@@ -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<NetDevice> 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<NetDevice> nd1;
Ptr<NetDevice> 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 <prefix>-<node id>-<device id>.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> 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<Ipv4> protocol1 = node1->GetObject<Ipv4> ();
Ptr<Ipv4> protocol2 = node2->GetObject<Ipv4> ();
@@ -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 <prefix>-n<node id>-i<interface>.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;
...

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

@@ -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'

18
doc/models/Makefile
View File

@@ -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 \

1
doc/models/source/emulation-overview.rst
View File

@@ -83,5 +83,6 @@ simulated |ns3| networks.
.. toctree::
emu
fd-net-device
tap

3
doc/models/source/index.rst
View File

@@ -26,6 +26,7 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
buildings
click
csma
data-collection
dsdv
dsr
emulation-overview
@@ -41,7 +42,7 @@ This document is written in `reStructuredText <http://docutils.sourceforge.net/r
openflow-switch
point-to-point
propagation
statistics
spectrum
topology
uan
wifi

12
src/brite/doc/brite.rst
View File

@@ -85,7 +85,7 @@ can be found in the BRITE user manual.
Building BRITE Integration
==========================
The first step is to download and build the ns-3 specific BRITE repository:::
The first step is to download and build the ns-3 specific BRITE repository::
$ hg clone http://code.nsnam.org/BRITE
$ cd BRITE
@@ -95,7 +95,7 @@ This will build BRITE and create a library, libbrite.so, within the BRITE
directory.
Once BRITE has been built successfully, we proceed to configure ns-3 with
BRITE support. Change to your ns-3 directory:::
BRITE support. Change to your ns-3 directory::
$ ./waf configure --with-brite=/your/path/to/brite/source --enable-examples
@@ -103,14 +103,14 @@ Make sure it says 'enabled' beside 'BRITE Integration'. If it does not, then
something has gone wrong. Either you have forgotten to build BRITE first
following the steps above, or ns-3 could not find your BRITE directory.
Next, build ns-3:::
Next, build ns-3::
$ ./waf
Examples
========
For an example demonstrating BRITE integration
run:::
run::
$ ./waf --run 'brite-generic-example'
@@ -131,13 +131,13 @@ many other command-line parameters including confFile, tracing, and nix, describ
Enables nix-vector routing. Global routing is used by default.
The generic BRITE example also support visualization using pyviz, assuming
python bindings in ns-3 are enabled:::
python bindings in ns-3 are enabled::
$ ./waf --run brite-generic-example --vis
Simulations involving BRITE can also be used with MPI. The total number of MPI instances is
passed to the BRITE topology helper where a modulo divide is used to assign the nodes for each
AS to a MPI instance. An example can be found in src/brite/examples:::
AS to a MPI instance. An example can be found in src/brite/examples::
$ mpirun -np 2 ./waf --run brite-MPI-example

4
src/csma/doc/csma.rst
View File

@@ -109,7 +109,7 @@ the simulator is single threaded, access to the common channel will be
serialized by the simulator. This provides a deterministic mechanism for
contending for the channel. The channel is allocated (transitioned from state
``IDLE`` to state ``TRANSMITTING``) on a first-come first-served basis.
The channel always goes through a three state process:::
The channel always goes through a three state process::
IDLE -> 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);

6
src/emu/doc/emu.rst
View File

@@ -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));

20
src/internet/doc/internet-stack.rst
View File

@@ -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> 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<Ipv4L3Protocol> ()`` to obtain a
pointer, as follows:::
pointer, as follows::
Ptr<Ipv4L3Protocol> ipv4 = m_node->GetObject<Ipv4L3Protocol> ();
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<const Packet> 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<Udp> udpSocketFactory = GetNode ()->GetObject<Udp> ();
Ptr<Socket> 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<void, Ptr<Socket>,
Ptr<Packet>,
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));

20
src/internet/doc/routing-overview.rst
View File

@@ -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<Node> >::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<Ipv4RoutingProtocol> 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<MyRoutingProtocol> myRoutingProto = CreateObject<MyRoutingProtocol> ();
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;

14
src/internet/doc/tcp.rst
View File

@@ -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 <http://en.wikipedia.org/wiki/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

16
src/mpi/doc/distributed.rst
View File

@@ -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<Node> node1 = CreateObject<Node> (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)
{

24
src/network/doc/packets.rst
View File

@@ -162,7 +162,7 @@ The following command will create a new packet with a new unique Id.::
Ptr<Packet> pkt = Create<Packet> ();
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<Packet> pkt = Create<Packet> (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<Packet> pkt1 = Create<Packet> (reinterpret_cast<const uint8_t*> ("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<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/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<Packet> frag0 = p->CreateFragment (0, 10);
Ptr<Packet> 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
*/

2
src/network/doc/sockets-api.rst
View File

@@ -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 ();

2
src/point-to-point/doc/point-to-point.rst
View File

@@ -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);

1
src/stats/doc/data-collection.rst
View File

@@ -32,5 +32,6 @@ low-level coding examples.
collector.rst
aggregator.rst
adaptor.rst
statistics.rst
scope-and-limitations.rst

14
src/wifi/doc/wifi.rst
View File

@@ -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> 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);

8
src/wimax/doc/wimax.rst
View File

@@ -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<SimpleOfdmWimaxChannel> ();
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;