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

tuturial fixes

Browse Source
This commit is contained in:
Andrey Hippo
2009-06-15 15:22:33 -07:00
parent 30bf674bb5
commit 582b959a4d
5 changed files with 56 additions and 57 deletions
Download Patch File Download Diff File Expand all files Collapse all files

30
doc/tutorial/building-topologies.texi
View File

@@ -248,7 +248,7 @@ from network number 10.1.2.0 in this case, as seen below.
Now we have a topology built, but we need applications. This section is
going to be fundamentally similar to the applications section of
@code{first.cc} but we are going to instantiate the server on one of the
nodes that has a CSMA node and the client on the node having only a
nodes that has a CSMA device and the client on the node having only a
point-to-point device.
First, we set up the echo server. We create a @code{UdpEchoServerHelper} and
@@ -296,7 +296,7 @@ leftmost point-to-point node seen in the topology illustration.
Since we have actually built an internetwork here, we need some form of
internetwork routing. @command{ns-3} provides what we call a global route
manager to set up the routing tables on nodes. This route manager has a
global function that runs though the nodes created for the simulation and does
global function that runs through the nodes created for the simulation and does
the hard work of setting up routing for you.
Basically, what happens is that each node behaves as if it were an OSPF router
@@ -317,7 +317,7 @@ you haven't encountered yet.
@verbatim
PointToPointHelper::EnablePcapAll ("second");
CsmaHelper::EnablePcap ("second", csmaDevices.Get (0), true);
CsmaHelper::EnablePcap ("second", csmaDevices.Get (1), true);
@end verbatim
The CSMA network is a multi-point-to-point network. This means that there
@@ -336,8 +336,8 @@ In this example, we are going to select one of the devices on the CSMA
network and ask it to perform a promiscuous sniff of the network, thereby
emulating what @code{tcpdump} would do. If you were on a Linux machine
you might do something like @code{tcpdump -i eth0} to get the trace.
In this case, we specify the device using @code{csmaDevices.Get(0)},
which selects the zeroth device in the container. Setting the final
In this case, we specify the device using @code{csmaDevices.Get(1)},
which selects the first device in the container. Setting the final
parameter to true enables promiscuous captures.
The last section of code just runs and cleans up the simulation just like
@@ -374,7 +374,7 @@ run the program.
@verbatim
export NS_LOG=
./waf --run scratch/mysecond
#end verbatim
@end verbatim
Since we have set up the UDP echo applications to log just as we did in
@code{first.cc}, you will see similar output when you run the script.
@@ -395,7 +395,7 @@ the echo packet. The final message, @code{Received 1024 bytes from 10.1.2.4}
is from the echo client, indicating that it has received its echo back from
the server.
If you now go and look in the top level directory, you will find two trace
If you now go and look in the top level directory, you will find three trace
files:
@verbatim
@@ -648,7 +648,7 @@ was in non-promiscuous mode.
To illustrate the difference between promiscuous and non-promiscuous traces, we
also requested a non-promiscuous trace for the next-to-last node. Go ahead and
take a look at the @code{tcpdump} for @code{second-10-0.pcap}.
take a look at the @code{tcpdump} for @code{second-100-0.pcap}.
@verbatim
tcpdump -nn -tt -r second-100-0.pcap
@@ -845,11 +845,11 @@ helpers:
For simplicity, this code uses the default PHY layer configuration and
channel models which are documented in the API doxygen documentation for
the @code{YansWifiChannelHelper::Default} and @code{YAnsWifiPhyHelper::Default}
the @code{YansWifiChannelHelper::Default} and @code{YansWifiPhyHelper::Default}
methods. Once these objects are created, we create a channel object
and associate it to our PHY layer object manager to make sure
that all the PHY objects created layer by the @code{YansWifiPhyHelper}
all share the same underlying channel, that is, they share the same
that all the PHY layer objects created by the @code{YansWifiPhyHelper}
share the same underlying channel, that is, they share the same
wireless medium and can communication and interfere:
@verbatim
@@ -1111,9 +1111,9 @@ third-0-0.pcap third-0-1.pcap third-1-0.pcap third-1-1.pcap
@end verbatim
The file ``third-0-0.pcap'' corresponds to the point-to-point device on node
zero -- the left side of the ``backbone.'' The file ``third-1-0.pcap''
zero -- the left side of the ``backbone''. The file ``third-1-0.pcap''
corresponds to the point-to-point device on node one -- the right side of the
``backbone.'' The file ``third-0-1.pcap'' will be the promiscuous (monitor
``backbone''. The file ``third-0-1.pcap'' will be the promiscuous (monitor
mode) trace from the Wifi network and the file ``third-1-1.pcap'' will be the
promiscuous trace from the CSMA network. Can you verify this by inspecting
the code?
@@ -1329,9 +1329,9 @@ If you are feeling brave, there is a list of all trace sources in the
@uref{http://www.nsnam.org/doxygen-release/index.html,,ns-3 Doxygen}
which you can find in the ``Modules'' tab.
Under the ``core'' section, you will find a link to ``The list of all trace
sources.'' You may find it interesting to try and hook some of these
sources.''. You may find it interesting to try and hook some of these
traces yourself. Additionally in the ``Modules'' documentation, there is
a link to ``The list of all attributes.'' You can set the default value of
a link to ``The list of all attributes.''. You can set the default value of
any of these @code{Attributes} via the command line as we have previously
discussed.

12
doc/tutorial/conceptual-overview.texi
View File

@@ -276,7 +276,7 @@ done a
@end verbatim
to build the project. So now if you look in the directory
@code{build/debug/ns-3} you will find the four module include files shown
@code{build/debug/ns3} you will find the four module include files shown
above. You can take a look at the contents of these files and find that they
do include all of the public include files in their respective modules.
@@ -308,8 +308,8 @@ The next line of the script is the following,
We will use this statement as a convenient place to talk about our Doxygen
documentation system. If you look at the project web site,
@uref{http://www.nsnam.org,,ns-3 project}, you will find a link to ``APIs
(Doxygen)'' in the navigation bar. If you select this link, you will be
@uref{http://www.nsnam.org,,ns-3 project}, you will find a link to ``Doxygen
(ns-3-dev)'' in the navigation bar. If you select this link, you will be
taken to our documentation page.
Along the left side, you will find a graphical representation of the structure
@@ -601,7 +601,7 @@ since we passed a @code{NodeContainer} containing one node) created by the
helper.
Applications require a time to ``start'' generating traffic and may take an
optional time to ``stop.'' We provide both. These times are set using the
optional time to ``stop''. We provide both. These times are set using the
@code{ApplicationContainer} methods @code{Start} and @code{Stop}. These
methods take @code{Time} parameters. In this case, we use an explicit C++
conversion sequence to take the C++ double 1.0 and convert it to an
@@ -815,12 +815,12 @@ drwxr-xr-x utils files
The source code is mainly in the @code{src} directory. You can view source
code either by clicking on the directory name or by clicking on the @code{files}
link to the right of the directory name. If you click on the @code{src}
directory you be taken to the lising of the @code{src} subdirectories. If you
directory, you will be taken to the listing of the @code{src} subdirectories. If you
click on @code{core} subdirectory, you will find a list of files. The first file
you will find (as of this writing) is @code{abort.h}. If you
click on @code{abort.h} link, you will be sent to the source file for @code{abort.h}.
Our example scripts are in the @code{examples} directory. The source code for
the helpers we have used in this chapter can be found in the
@code{src/helpers} directory. Feel free to poke around in the directory tree to
@code{src/helper} directory. Feel free to poke around in the directory tree to
get a feel for what is there and the style of @command{ns-3} programs.

27
doc/tutorial/getting-started.texi
View File

@@ -44,7 +44,7 @@ the Getting Started section of the @command{ns-3} web site:
@cindex tarball
The @command{ns-3} code is available in Mercurial repositories on the server
code.nsnam.org. You can also download a tarball release at
@uref{http://code.nsnam.org}. You can also download a tarball release at
@uref{http://www.nsnam.org/releases/}, or you can work with repositories
using Mercurial. We recommend using Mercurial unless there's a good reason
not to. See the end of this section for instructions on how to get a tarball
@@ -53,7 +53,7 @@ release.
@cindex repository
The simplest way to get started using Mercurial repositories is to use the
@code{ns-3-allinone} environment. This is a set of scripts that manages the
downloading and building of various subystems of @command{ns-3} for you. We
downloading and building of various subsystems of @command{ns-3} for you. We
recommend that you begin your @command{ns-3} adventures in this environment
as it can really simplify your life at this point.
@@ -128,12 +128,13 @@ Since the release numbers are going to be changing, I will stick with
the more constant ns-3-dev here in the tutorial, but you can replace the
string ``ns-3-dev'' with your choice of release (e.g., ns-3.4 and
ns-3.4-ref-traces) in the text below. You can find the latest version of the
code either by inspection of the repository list or by going to the ``Getting
Started'' web page and looking for the latest release identifier.
code either by inspection of the repository list or by going to the
@uref{http://www.nsnam.org/getting_started.html,,``Getting Started''}
web page and looking for the latest release identifier.
Go ahead and change into the @code{ns-3-allinone} directory you created when
you cloned that repository. We are now going to use the @code{download.py}
script to pull down the various pieces of @command{ns-3} you will be using/
script to pull down the various pieces of @command{ns-3} you will be using.
Go ahead and type the following into your shell (remember you can substitute
the name of your chosen release number instead of @code{ns-3-dev} -- like
@@ -257,15 +258,15 @@ get a copy of a release by typing the following into your Linux shell
mkdir tarballs
cd tarballs
wget http://www.nsnam.org/releases/ns-allinone-3.4.tar.bz2
tar xjf ns-3.4.tar.bz2
tar xjf ns-allinone-3.4.tar.bz2
@end verbatim
If you change into the directory @code{ns-allinone-3.4} you should see a
number of files:
@verbatim
build.py* ns-3.4-RC2/ nsc-0.5.0/ util.py
constants.py ns-3.4-RC2-ref-traces/ pybindgen-0.10.0.630/
build.py* ns-3.4/ nsc-0.5.0/ README
constants.py ns-3.4-ref-traces/ pybindgen-0.10.0.630/ util.py
@end verbatim
You are now ready to build the @command{ns-3} distribution.
@@ -404,7 +405,7 @@ Configuration finished successfully (00:00:02); project is now ready to build.
@end verbatim
Note the last part of the above output. Some ns-3 options are not enabled by
default or require support from the underlying system to work properly
default or require support from the underlying system to work properly.
For instance, to enable XmlTo, the library libxml-2.0 must be found on the
system. in the example above, this library was not found and the corresponding
feature was not enabled. There is a feature to use sudo to set the suid bit of
@@ -438,7 +439,7 @@ programs to run as root. There are many other configure- and build-time options
available in waf. To explore these options, type:
@verbatim
./waf -- help
./waf --help
@end verbatim
We'll use some of the testing-related commands in the next section.
@@ -488,7 +489,7 @@ This command is typically run by @code{users} to quickly verify that an
@cindex regression tests
You can also run our regression test suite to ensure that your distribution and
tool chain have produced binaries that generate output that is identical to
toolchain have produced binaries that generate output that is identical to
known-good reference output files. You downloaded these reference traces to
your machine during the download process above. (Warning: The @code{ns-3.2}
and @code{ns-3.3} releases do not use the @code{ns-3-allinone} environment
@@ -505,7 +506,7 @@ along with a suggestion on diff parameters and options in order to see what
has gone awry. If the error was discovered in a pcap file, it will be useful
to convert the pcap files to text using tcpdump prior to comparison.
Some regression tests wmay be SKIPped if the required support
Some regression tests may be SKIPped if the required support
is not present.
To run the regression tests, you provide Waf with the regression flag.
@@ -568,7 +569,7 @@ ubiquitous hello world program by typing the following:
@end verbatim
Waf first checks to make sure that the program is built correctly and
executes a build if required. Waf then then executes the program, which
executes a build if required. Waf then executes the program, which
produces the following output.
@verbatim

8
doc/tutorial/introduction.texi
View File

@@ -226,7 +226,7 @@ only have to understand a tiny and intuitively obvious subset of Python in
order to extend the system in most cases.
For those interested in the gory details of Waf, the main web site can be
found at @uref{http://freehackers.org/~tnagy/waf.html}.
found at @uref{http://code.google.com/p/waf/}.
@node Development Environment
@section Development Environment
@@ -275,7 +275,7 @@ problems.
@cindex MinGW
If you do use Cygwin or MinGW; and use Logitech products, we will save you
quite a bit of heartburn right off the bat and encourage you to take a look
at the @uref{http://www.mingw.org/MinGWiki/index.php/FAQ,,MinGW FAQ}.
at the @uref{http://oldwiki.mingw.org/index.php/FAQ,,MinGW FAQ}.
@cindex Logitech
Search for ``Logitech'' and read the FAQ entry, ``why does make often
@@ -295,7 +295,7 @@ such as VMware server and install a Linux virtual machine.
We will assume a basic facility with the Berkeley Sockets API in the examples
used in this tutorial. If you are new to sockets, we recommend reviewing the
API and some common usage cases. For a good overview of programming TCP/IP
sockets we recommend @uref{http://www.elsevier.com/wps/product/cws_home/680765,,Practical TCP/IP Sockets in C, Donahoo and Calvert}.
sockets we recommend @uref{http://www.elsevier.com/wps/find/bookdescription.cws_home/717656/description#description,,TCP/IP Sockets in C, Donahoo and Calvert}.
There is an associated web site that includes source for the examples in the
book, which you can find at:
@@ -305,6 +305,6 @@ If you understand the first four chapters of the book (or for those who do
not have access to a copy of the book, the echo clients and servers shown in
the website above) you will be in good shape to understand the tutorial.
There is a similar book on Multicast Sockets,
@uref{http://www.elsevier.com/wps/product/cws_home/700736,,Multicast Sockets, Makofske and Almeroth}.
@uref{http://www.elsevier.com/wps/find/bookdescription.cws_home/700736/description#description,,Multicast Sockets, Makofske and Almeroth}.
that covers material you may need to understand if you look at the multicast
examples in the distribution.

36
doc/tutorial/tweaking.texi
View File

@@ -112,7 +112,7 @@ actually logging messages from the @code{UdpEchoClientApplication} and
example, to print more information by setting its logging level via the
NS_LOG environment variable.
I am going to assume from here on that are using an sh-like shell that uses
I am going to assume from here on that you are using an sh-like shell that uses
the``VARIABLE=value'' syntax. If you are using a csh-like shell, then you
will have to convert my examples to the ``setenv VARIABLE value'' syntax
required by those shells.
@@ -353,7 +353,7 @@ Recall that we have defined a logging component in that script:
You now know that you can enable all of the logging for this component by
setting the @code{NS_LOG} environment variable to the various levels. Let's
go ahead add some logging to the script. The macro used to add an
go ahead and add some logging to the script. The macro used to add an
informational level log message is @code{NS_LOG_INFO}. Go ahead and add one
(just before we start creating the nodes) that tells you that the script is
``Creating Topology.'' This is done as in this code snippet,
@@ -439,7 +439,7 @@ in the following code,
This simple two line snippet is actually very useful by itself. It opens the
door to the @command{ns-3} global variable and @code{Attribute} systems. Go
ahead and add that two lines of code to the @code{scratch/first.cc} script at
ahead and add that two lines of code to the @code{scratch/myfirst.cc} script at
the start of @code{main}. Go ahead and build the script and run it, but ask
the script for help in the following way,
@@ -497,7 +497,7 @@ is created in the system. We overrode this default with the @code{Attribute}
setting in the @code{PointToPointHelper} above. Let's use the default values
for the point-to-point devices and channels by deleting the
@code{SetDeviceAttribute} call and the @code{SetChannelAttribute} call from
the @code{first.cc} we have in the scratch directory.
the @code{myfirst.cc} we have in the scratch directory.
Your script should now just declare the @code{PointToPointHelper} and not do
any @code{set} operations as in the following example,
@@ -801,8 +801,8 @@ the script just after the GNU GPL comment:
#include <fstream>
@end verbatim
Then, right before the before the call to @code{Simulator::Run ()}, add the
following lines of code.
Then, right before the call to @code{Simulator::Run ()}, add the
following lines of code:
@verbatim
std::ofstream ascii;
@@ -811,7 +811,7 @@ following lines of code.
@end verbatim
The first two lines are just vanilla C++ code to open a stream that will be
written to a file named ``myfirst.tr.'' See your favorite C++ tutorial if you
written to a file named ``myfirst.tr''. See your favorite C++ tutorial if you
are unfamiliar with this code. The last line of code in the snippet above
tells @command{ns-3} that you want to enable ASCII tracing on all
point-to-point devices in your simulation; and you want the (provided) trace
@@ -900,7 +900,7 @@ managed in the @command{ns-3} core code that contains all of the nodes that are
created in a script. Just as a filesystem may have directories under the
root, we may have node numbers in the @code{NodeList}. The string
@code{/NodeList/0} therefore refers to the zeroth node in the @code{NodeList}
which we typically think of as ``node 0.'' In each node there is a list of
which we typically think of as ``node 0''. In each node there is a list of
devices that have been installed. This list appears next in the namespace.
You can see that this trace event comes from @code{DeviceList/0} which is the
zeroth device installed in the node.
@@ -928,14 +928,12 @@ device on the node with the echo server. I have reproduced that event below.
00 r
01 2.25732
02 /NodeList/1/DeviceList/0/$ns3::PointToPointNetDevice/MacRx
03 ns3::PppHeader (
04 Point-to-Point Protocol: IP (0x0021))
05 ns3::Ipv4Header (
06 tos 0x0 ttl 64 id 0 offset 0 flags [none]
07 length: 1052 10.1.1.1 > 10.1.1.2)
08 ns3::UdpHeader (
09 length: 1032 49153 > 9)
10 Payload (size=1024)
03 ns3::Ipv4Header (
04 tos 0x0 ttl 64 id 0 protocol 17 offset 0 flags [none]
05 length: 1052 10.1.1.1 > 10.1.1.2)
06 ns3::UdpHeader (
07 length: 1032 49153 > 9)
08 Payload (size=1024)
@end verbatim
Notice that the trace operation is now @code{r} and the simulation time has
@@ -978,7 +976,7 @@ file names will be built using the prefix, the node number, the device number
and a ``.pcap'' suffix.
In our example script, we will eventually see files named ``myfirst-0-0.pcap''
and ``myfirst.1-0.pcap'' which are the pcap traces for node 0-device 0 and
and ``myfirst-1-0.pcap'' which are the pcap traces for node 0-device 0 and
node 1-device 0, respectively.
Once you have added the line of code to enable pcap tracing, you can run the
@@ -1010,9 +1008,9 @@ at the @code{pcap} files.
2.257324 IP 10.1.1.2.9 > 10.1.1.1.49153: UDP, length 1024
@end verbatim
You can see in the dump of @code{myfirst-0.0.pcap} (the client device) that the
You can see in the dump of @code{myfirst-0-0.pcap} (the client device) that the
echo packet is sent at 2 seconds into the simulation. If you look at the
second dump (@code{first-1-0.pcap}) you can see that packet being received
second dump (@code{myfirst-1-0.pcap}) you can see that packet being received
at 2.257324 seconds. You see the packet being echoed back at 2.257324 seconds
in the second dump, and finally, you see the packet being received back at
the client in the first dump at 2.514648 seconds.