From 582b959a4d73b68b57bb297b59ce03b4fcefe058 Mon Sep 17 00:00:00 2001 From: Andrey Hippo Date: Mon, 15 Jun 2009 15:22:33 -0700 Subject: [PATCH] tuturial fixes --- doc/tutorial/building-topologies.texi | 30 +++++++++++----------- doc/tutorial/conceptual-overview.texi | 12 ++++----- doc/tutorial/getting-started.texi | 27 ++++++++++---------- doc/tutorial/introduction.texi | 8 +++--- doc/tutorial/tweaking.texi | 36 +++++++++++++-------------- 5 files changed, 56 insertions(+), 57 deletions(-) diff --git a/doc/tutorial/building-topologies.texi b/doc/tutorial/building-topologies.texi index 17d8156cb..010a55418 100644 --- a/doc/tutorial/building-topologies.texi +++ b/doc/tutorial/building-topologies.texi @@ -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. diff --git a/doc/tutorial/conceptual-overview.texi b/doc/tutorial/conceptual-overview.texi index cb38386bb..aa914c774 100644 --- a/doc/tutorial/conceptual-overview.texi +++ b/doc/tutorial/conceptual-overview.texi @@ -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. diff --git a/doc/tutorial/getting-started.texi b/doc/tutorial/getting-started.texi index a4bc52aac..76ad4daf3 100644 --- a/doc/tutorial/getting-started.texi +++ b/doc/tutorial/getting-started.texi @@ -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 diff --git a/doc/tutorial/introduction.texi b/doc/tutorial/introduction.texi index 299264155..0fa1f05b3 100644 --- a/doc/tutorial/introduction.texi +++ b/doc/tutorial/introduction.texi @@ -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. diff --git a/doc/tutorial/tweaking.texi b/doc/tutorial/tweaking.texi index 8a7ebcbf5..ad25e14ff 100644 --- a/doc/tutorial/tweaking.texi +++ b/doc/tutorial/tweaking.texi @@ -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 @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.