--- a/doc/tutorial/building-topologies.texi Fri Jun 12 12:33:57 2009 +0100
+++ b/doc/tutorial/building-topologies.texi Mon Jun 15 15:22:33 2009 -0700
@@ -248,7 +248,7 @@
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 @@
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 @@
@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 @@
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 @@
@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 @@
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 @@
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 @@
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 @@
@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 @@
@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.
--- a/doc/tutorial/conceptual-overview.texi Fri Jun 12 12:33:57 2009 +0100
+++ b/doc/tutorial/conceptual-overview.texi Mon Jun 15 15:22:33 2009 -0700
@@ -276,7 +276,7 @@
@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 @@
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 @@
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 @@
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.
--- a/doc/tutorial/getting-started.texi Fri Jun 12 12:33:57 2009 +0100
+++ b/doc/tutorial/getting-started.texi Mon Jun 15 15:22:33 2009 -0700
@@ -44,7 +44,7 @@
@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 @@
@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 @@
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 @@
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 @@
@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 @@
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 @@
@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 @@
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 @@
@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
--- a/doc/tutorial/introduction.texi Fri Jun 12 12:33:57 2009 +0100
+++ b/doc/tutorial/introduction.texi Mon Jun 15 15:22:33 2009 -0700
@@ -226,7 +226,7 @@
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 @@
@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 @@
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 @@
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.
--- a/doc/tutorial/tweaking.texi Fri Jun 12 12:33:57 2009 +0100
+++ b/doc/tutorial/tweaking.texi Mon Jun 15 15:22:33 2009 -0700
@@ -112,7 +112,7 @@
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 @@
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 @@
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 @@
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 @@
#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 @@
@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 @@
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 @@
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 @@
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 @@
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.