1.1 --- a/doc/tutorial/building-topologies.texi Wed Jul 01 12:47:40 2009 +0200
1.2 +++ b/doc/tutorial/building-topologies.texi Wed Jul 01 23:08:07 2009 -0700
1.3 @@ -61,7 +61,6 @@
1.4 #include "ns3/simulator-module.h"
1.5 #include "ns3/node-module.h"
1.6 #include "ns3/helper-module.h"
1.7 - #include "ns3/global-routing-module.h"
1.8 @end verbatim
1.9
1.10 One thing that can be surprisingly useful is a small bit of ASCII art that
1.11 @@ -294,10 +293,11 @@
1.12 @end verbatim
1.13
1.14 Since we have actually built an internetwork here, we need some form of
1.15 -internetwork routing. @command{ns-3} provides what we call a global route
1.16 -manager to set up the routing tables on nodes. This route manager has a
1.17 -global function that runs through the nodes created for the simulation and does
1.18 -the hard work of setting up routing for you.
1.19 +internetwork routing. @command{ns-3} provides what we call global routing to
1.20 +help you out. Global routing takes advantage of the fact that the entire
1.21 +internetwork is accessible in the simulation and runs through the all of the
1.22 +nodes created for the simulation --- it does the hard work of setting up routing
1.23 +for you without having to configure routers.
1.24
1.25 Basically, what happens is that each node behaves as if it were an OSPF router
1.26 that communicates instantly and magically with all other routers behind the
1.27 @@ -307,7 +307,7 @@
1.28 is a one-liner:
1.29
1.30 @verbatim
1.31 - GlobalRouteManager::PopulateRoutingTables ();
1.32 + Ipv4GlobalRoutingHelper::PopulateRoutingTables ();
1.33 @end verbatim
1.34
1.35 Next we enable pcap tracing. The first line of code to enable pcap tracing
1.36 @@ -329,8 +329,8 @@
1.37 one of the devices and place it in promiscuous mode. That single device
1.38 then ``sniffs'' the network for all packets and stores them in a single
1.39 pcap file. This is how @code{tcpdump}, for example, works. That final
1.40 -parameter tells the CSMA helper whether or not to capture packets in
1.41 -promiscuous mode.
1.42 +parameter tells the CSMA helper whether or not to arrange to capture
1.43 +packets in promiscuous mode.
1.44
1.45 In this example, we are going to select one of the devices on the CSMA
1.46 network and ask it to perform a promiscuous sniff of the network, thereby
1.47 @@ -350,10 +350,10 @@
1.48 }
1.49 @end verbatim
1.50
1.51 -In order to run this example, you have to copy the @code{second.cc} example
1.52 -script into the scratch directory and use waf to build just as you did with
1.53 +In order to run this example, copy the @code{second.cc} example script into
1.54 +the scratch directory and use waf to build just as you did with
1.55 the @code{first.cc} example. If you are in the top-level directory of the
1.56 -repository you would type,
1.57 +repository you just type,
1.58
1.59 @verbatim
1.60 cp examples/second.cc scratch/mysecond.cc
1.61 @@ -380,18 +380,19 @@
1.62 @code{first.cc}, you will see similar output when you run the script.
1.63
1.64 @verbatim
1.65 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
1.66 - Build finished successfully (00:00:00)
1.67 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.68 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.69 + 'build' finished successfully (0.415s)
1.70 Sent 1024 bytes to 10.1.2.4
1.71 Received 1024 bytes from 10.1.1.1
1.72 Received 1024 bytes from 10.1.2.4
1.73 @end verbatim
1.74
1.75 -Recall that the first message, @code{Sent 1024 bytes to 10.1.2.4} is the
1.76 +Recall that the first message, ``@code{Sent 1024 bytes to 10.1.2.4},'' is the
1.77 UDP echo client sending a packet to the server. In this case, the server
1.78 -is on a different network (10.1.2.0). The second message, @code{Received 1024
1.79 -bytes from 10.1.1.1}, is from the UDP echo server, generated when it receives
1.80 -the echo packet. The final message, @code{Received 1024 bytes from 10.1.2.4}
1.81 +is on a different network (10.1.2.0). The second message, ``@code{Received 1024
1.82 +bytes from 10.1.1.1},'' is from the UDP echo server, generated when it receives
1.83 +the echo packet. The final message, ``@code{Received 1024 bytes from 10.1.2.4},''
1.84 is from the echo client, indicating that it has received its echo back from
1.85 the server.
1.86
1.87 @@ -483,8 +484,8 @@
1.88 doesn't know the MAC address of the corresponding node. It broadcasts on the
1.89 CSMA network (ff:ff:ff:ff:ff:ff) asking for the device that has IP address
1.90 10.1.2.4. In this case, the rightmost node replies saying it is at MAC address
1.91 -00:00:00:00:00:06. (Note that node two is not directly involved in this
1.92 -exchange, but is sniffing the network and reporting all of the traffic it sees.)
1.93 +00:00:00:00:00:06. Note that node two is not directly involved in this
1.94 +exchange, but is sniffing the network and reporting all of the traffic it sees.
1.95
1.96 This exchange is seen in the following lines,
1.97
1.98 @@ -559,8 +560,9 @@
1.99 You should now see,
1.100
1.101 @verbatim
1.102 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
1.103 - Build finished successfully (00:00:00)
1.104 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.105 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.106 + 'build' finished successfully (0.405s)
1.107 Sent 1024 bytes to 10.1.2.5
1.108 Received 1024 bytes from 10.1.1.1
1.109 Received 1024 bytes from 10.1.2.5
1.110 @@ -572,7 +574,7 @@
1.111 It is possible that you may not be satisfied with a trace file generated by
1.112 a bystander in the CSMA network. You may really want to get a trace from
1.113 a single device and you may not be interested in any other traffic on the
1.114 -network. You can do this,
1.115 +network. You can do this fairly easily/
1.116
1.117 Let's take a look at @code{scratch/mysecond.cc} and add that code enabling us
1.118 to be more specific. @code{ns-3} helpers provide methods that take a node
1.119 @@ -615,6 +617,14 @@
1.120 documentation for the method. Using the @code{GetId} method can make
1.121 determining node numbers much easier in complex topologies.
1.122
1.123 +Let's clear the old trace files out of the top-level directory to avoid confusion
1.124 +about what is going on,
1.125 +
1.126 +@verbatim
1.127 + rm *.pcap
1.128 + rm *.tr
1.129 +@end verbatim
1.130 +
1.131 If you build the new script and run the simulation setting @code{nCsma} to 100,
1.132
1.133 @verbatim
1.134 @@ -624,8 +634,9 @@
1.135 you will see the following output:
1.136
1.137 @verbatim
1.138 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
1.139 - Build finished successfully (00:00:00)
1.140 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.141 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.142 + 'build' finished successfully (0.407s)
1.143 Sent 1024 bytes to 10.1.2.101
1.144 Received 1024 bytes from 10.1.1.1
1.145 Received 1024 bytes from 10.1.2.101
1.146 @@ -659,9 +670,27 @@
1.147 entire CSMA network.
1.148
1.149 @verbatim
1.150 -reading from file second-100-0.pcap, link-type EN10MB (Ethernet)
1.151 -2.003696 arp who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
1.152 -2.003811 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.101
1.153 + reading from file second-100-0.pcap, link-type EN10MB (Ethernet)
1.154 + 2.003696 arp who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
1.155 + 2.003811 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.101
1.156 +@end verbatim
1.157 +
1.158 +Now take a look at the @code{tcpdump} for @code{second-101-0.pcap}.
1.159 +
1.160 +@verbatim
1.161 + tcpdump -nn -tt -r second-101-0.pcap
1.162 +@end verbatim
1.163 +
1.164 +You can now see that node 101 is really the participant in the echo exchange.
1.165 +
1.166 +@verbatim
1.167 + reading from file second-101-0.pcap, link-type EN10MB (Ethernet)
1.168 + 2.003696 arp who-has 10.1.2.101 (ff:ff:ff:ff:ff:ff) tell 10.1.2.1
1.169 + 2.003696 arp reply 10.1.2.101 is-at 00:00:00:00:00:67
1.170 + 2.003801 IP 10.1.1.1.49153 > 10.1.2.101.9: UDP, length 1024
1.171 + 2.003801 arp who-has 10.1.2.1 (ff:ff:ff:ff:ff:ff) tell 10.1.2.101
1.172 + 2.003822 arp reply 10.1.2.1 is-at 00:00:00:00:00:03
1.173 + 2.003822 IP 10.1.2.101.9 > 10.1.1.1.49153: UDP, length 1024
1.174 @end verbatim
1.175
1.176 @c ========================================================================
1.177 @@ -714,7 +743,6 @@
1.178 #include "ns3/simulator-module.h"
1.179 #include "ns3/node-module.h"
1.180 #include "ns3/helper-module.h"
1.181 -#include "ns3/global-routing-module.h"
1.182 #include "ns3/wifi-module.h"
1.183 #include "ns3/mobility-module.h"
1.184 @end verbatim
1.185 @@ -1035,14 +1063,15 @@
1.186 just as we did in the @code{second.cc} example script.
1.187
1.188 @verbatim
1.189 - GlobalRouteManager::PopulateRoutingTables ();
1.190 + Ipv4GlobalRoutingHelper::PopulateRoutingTables ();
1.191 @end verbatim
1.192
1.193 One thing that can surprise some users is the fact that the simulation we just
1.194 created will never ``naturally'' stop. This is because we asked the wireless
1.195 -access point to generate beacons. It will generate beacons forever, so we must
1.196 -tell the simulator to stop even though it may have beacon generation events
1.197 -scheduled. The following line of code tells the simulator to stop so that
1.198 +access point to generate beacons. It will generate beacons forever, and this
1.199 +will result in simulator events being scheduled into the future indefinitely,
1.200 +so we must tell the simulator to stop even though it may have beacon generation
1.201 +events scheduled. The following line of code tells the simulator to stop so that
1.202 we don't simulate beacons forever and enter what is essentially an endless
1.203 loop.
1.204
1.205 @@ -1054,7 +1083,7 @@
1.206
1.207 @verbatim
1.208 PointToPointHelper::EnablePcapAll ("third");
1.209 - YansWifiPhyHelper::EnablePcap ("third", apDevices.Get (0));
1.210 + phy.EnablePcap ("third", apDevices.Get (0));
1.211 CsmaHelper::EnablePcap ("third", csmaDevices.Get (0), true);
1.212 @end verbatim
1.213
1.214 @@ -1084,27 +1113,28 @@
1.215 ./waf --run scratch/mythird
1.216 @end verbatim
1.217
1.218 -Since we have set up the UDP echo applications just as we did in the
1.219 +Again, since we have set up the UDP echo applications just as we did in the
1.220 @code{second.cc} script, you will see similar output.
1.221
1.222 @verbatim
1.223 - Entering directory `repos/ns-3-allinone-dev/ns-3-dev/build'
1.224 - Build finished successfully (00:00:00)
1.225 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.226 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
1.227 + 'build' finished successfully (0.407s)
1.228 Sent 1024 bytes to 10.1.2.4
1.229 Received 1024 bytes from 10.1.3.3
1.230 Received 1024 bytes from 10.1.2.4
1.231 @end verbatim
1.232
1.233 -Recall that the first message, @code{Sent 1024 bytes to 10.1.2.4} is the
1.234 +Recall that the first message, ``@code{Sent 1024 bytes to 10.1.2.4},'' is the
1.235 UDP echo client sending a packet to the server. In this case, the client
1.236 is on the wireless network (10.1.3.0). The second message,
1.237 -@code{Received 1024 bytes from 10.1.3.3}, is from the UDP echo server,
1.238 +``@code{Received 1024 bytes from 10.1.3.3},'' is from the UDP echo server,
1.239 generated when it receives the echo packet. The final message,
1.240 -@code{Received 1024 bytes from 10.1.2.4} is from the echo client, indicating
1.241 +``@code{Received 1024 bytes from 10.1.2.4},'' is from the echo client, indicating
1.242 that it has received its echo back from the server.
1.243
1.244 If you now go and look in the top level directory, you will find four trace
1.245 -files, two from node zero and two from node one:
1.246 +files from this simulation, two from node zero and two from node one:
1.247
1.248 @verbatim
1.249 third-0-0.pcap third-0-1.pcap third-1-0.pcap third-1-1.pcap
1.250 @@ -1223,8 +1253,8 @@
1.251
1.252 Now, we spent a lot of time setting up mobility models for the wireless network
1.253 and so it would be a shame to finish up without even showing that the STA
1.254 -nodes are actually moving around. Let's do this by hooking into the
1.255 -@code{MobilityModel} course change trace source. This is usually considered
1.256 +nodes are actually moving around during the simulation. Let's do this by hooking
1.257 +into the @code{MobilityModel} course change trace source. This is usually considered
1.258 a fairly advanced topic, but let's just go for it.
1.259
1.260 As mentioned in the ``Tweaking ns-3'' section, the @command{ns-3} tracing system
1.261 @@ -1273,8 +1303,8 @@
1.262 /NodeList/7/$ns3::MobilityModel/CourseChange
1.263 @end verbatim
1.264
1.265 -Based on the discussion in the tracing section, you can easily infer that
1.266 -this trace path references the seventh node in the NodeList. It specifies
1.267 +Based on the discussion in the tracing section, you may infer that this trace
1.268 +path references the seventh node in the global NodeList. It specifies
1.269 what is called an aggregated object of type @code{ns3::MobilityModel}. The
1.270 dollar sign prefix implies that the MobilityModel is aggregated to node seven.
1.271 The last component of the path means that we are hooking into the
1.272 @@ -1336,6 +1366,6 @@
1.273 discussed.
1.274
1.275 We have just scratched the surface of @command{ns-3} in this tutorial, but we
1.276 -hope we have covered enough to get you started doing useful work.
1.277 +hope we have hopefully covered enough to get you started doing useful work.
1.278
1.279 -- The @command{ns-3} development team.
2.1 --- a/doc/tutorial/conceptual-overview.texi Wed Jul 01 12:47:40 2009 +0200
2.2 +++ b/doc/tutorial/conceptual-overview.texi Wed Jul 01 23:08:07 2009 -0700
2.3 @@ -110,7 +110,7 @@
2.4 you had to buy a specific kind of network cable and a hardware device called
2.5 (in PC terminology) a @emph{peripheral card} that needed to be installed in
2.6 your computer. If the peripheral card implemented some networking function,
2.7 -theys were called Network Interface Cards, or @emph{NICs}. Today most
2.8 +they were called Network Interface Cards, or @emph{NICs}. Today most
2.9 computers come with the network interface hardware built in and users don't
2.10 see these building blocks.
2.11
2.12 @@ -174,9 +174,10 @@
2.13 directory structure something like the following:
2.14
2.15 @verbatim
2.16 - AUTHORS examples/ README samples/ utils/ waf.bat*
2.17 - build/ LICENSE regression/ scratch/ VERSION wscript
2.18 - doc/ ns3/ RELEASE_NOTES src/ waf*
2.19 + AUTHORS doc/ README RELEASE_NOTES utils/ wscript
2.20 + bindings/ examples/ regression/ samples/ VERSION wutils.py
2.21 + build/ LICENSE regression.py scratch/ waf* wutils.pyc
2.22 + CHANGES.html ns3/ regression.pyc src/ waf.bat*
2.23 @end verbatim
2.24
2.25 @cindex first.cc
2.26 @@ -276,7 +277,7 @@
2.27 @end verbatim
2.28
2.29 to build the project. So now if you look in the directory
2.30 -@code{build/debug/ns3} you will find the four module include files shown
2.31 +@code{../build/debug/ns3} you will find the four module include files shown
2.32 above. You can take a look at the contents of these files and find that they
2.33 do include all of the public include files in their respective modules.
2.34
2.35 @@ -310,16 +311,18 @@
2.36 documentation system. If you look at the project web site,
2.37 @uref{http://www.nsnam.org,,ns-3 project}, you will find a link to ``Doxygen
2.38 (ns-3-dev)'' in the navigation bar. If you select this link, you will be
2.39 -taken to our documentation page.
2.40 +taken to our documentation page for the current development release. There
2.41 +is also a link to ``Doxygen (stable)'' that will take you to the documentation
2.42 +for the latest stable release of @code{ns-3}.
2.43
2.44 Along the left side, you will find a graphical representation of the structure
2.45 of the documentation. A good place to start is the @code{NS-3 Modules}
2.46 -``book.'' If you expand @code{Modules} you will see a list of @command{ns-3}
2.47 -module documentation. The concept of module here ties directly into the
2.48 -module include files discussed above. It turns out that the @command{ns-3}
2.49 -logging subsystem is part of the @code{core} module, so go ahead and expand
2.50 -that documentation node. Now, expand the @code{Debugging} book and then
2.51 -select the @code{Logging} page.
2.52 +``book'' in the @code{ns-3} navigation tree. If you expand @code{Modules}
2.53 +you will see a list of @command{ns-3} module documentation. The concept of
2.54 +module here ties directly into the module include files discussed above. It
2.55 +turns out that the @command{ns-3} logging subsystem is part of the @code{core}
2.56 +module, so go ahead and expand that documentation node. Now, expand the
2.57 +@code{Debugging} book and then select the @code{Logging} page.
2.58
2.59 You should now be looking at the Doxygen documentation for the Logging module.
2.60 In the list of @code{#define}s at the top of the page you will see the entry
2.61 @@ -437,7 +440,7 @@
2.62 pointToPoint.SetDeviceAttribute ("DataRate", StringValue ("5Mbps"));
2.63 @end verbatim
2.64
2.65 -tells the @code{PointToPointHelper} object to use the value ``5mbps''
2.66 +tells the @code{PointToPointHelper} object to use the value ``5Mbps''
2.67 (five megabits per second) as the ``DataRate'' when it creates a
2.68 @code{PointToPointNetDevice} object.
2.69
2.70 @@ -492,7 +495,7 @@
2.71 created objects.
2.72
2.73 After executing the @code{pointToPoint.Install (nodes)} call we will have
2.74 -two nodes, each with an installed point-to-point net device and a
2.75 +two nodes, each with an installed point-to-point net device and a single
2.76 point-to-point channel between them. Both devices will be configured to
2.77 transmit data at five megabits per second over the channel which has a two
2.78 millisecond transmission delay.
2.79 @@ -576,13 +579,13 @@
2.80 The first line of code in the above snippet declares the
2.81 @code{UdpEchoServerHelper}. As usual, this isn't the application itself, it
2.82 is an object used to help us create the actual applications. One of our
2.83 -conventions is to place required @code{Attributes} in the helper constructor.
2.84 +conventions is to place @emph{required} @code{Attributes} in the helper constructor.
2.85 In this case, the helper can't do anything useful unless it is provided with
2.86 a port number that the client also knows about. Rather than just picking one
2.87 and hoping it all works out, we require the port number as a parameter to the
2.88 constructor. The constructor, in turn, simply does a @code{SetAttribute}
2.89 -with the passed value. You can, if desired, set the ``Port'' @code{Attribute}
2.90 -to another value later.
2.91 +with the passed value. If you want, you can set the ``Port'' @code{Attribute}
2.92 +to another value later using @code{SetAttribute}.
2.93
2.94 Similar to many other helper objects, the @code{UdpEchoServerHelper} object
2.95 has an @code{Install} method. It is the execution of this method that actually
2.96 @@ -591,7 +594,11 @@
2.97 @code{NodeContainter} as a parameter just as the other @code{Install} methods
2.98 we have seen. This is actually what is passed to the method even though it
2.99 doesn't look so in this case. There is a C++ @emph{implicit conversion} at
2.100 -work here.
2.101 +work here that takes the result of @code{nodes.Get (1)} (which returns a smart
2.102 +pointer to a node object --- @code{Ptr<Node>}) and uses that in a constructor
2.103 +for an unnamed @code{NodeContainer} that is then passed to @code{Install}.
2.104 +If you are ever at a loss to find a particular method signature in C++ code
2.105 +that compiles and runs just fine, look for these kinds of implicit conversions.
2.106
2.107 We now see that @code{echoServer.Install} is going to install a
2.108 @code{UdpEchoServerApplication} on the node found at index number one of the
2.109 @@ -603,9 +610,12 @@
2.110 Applications require a time to ``start'' generating traffic and may take an
2.111 optional time to ``stop''. We provide both. These times are set using the
2.112 @code{ApplicationContainer} methods @code{Start} and @code{Stop}. These
2.113 -methods take @code{Time} parameters. In this case, we use an explicit C++
2.114 -conversion sequence to take the C++ double 1.0 and convert it to an
2.115 -@command{ns-3} @code{Time} object using a @code{Seconds} cast. The two lines,
2.116 +methods take @code{Time} parameters. In this case, we use an @emph{explicit}
2.117 +C++ conversion sequence to take the C++ double 1.0 and convert it to an
2.118 +@command{ns-3} @code{Time} object using a @code{Seconds} cast. Be aware that
2.119 +the conversion rules may be controlled by the model author, and C++ has its
2.120 +own rules, so you can't always just assume that parameters will be happily
2.121 +converted for you. The two lines,
2.122
2.123 @verbatim
2.124 serverApps.Start (Seconds (1.0));
2.125 @@ -614,9 +624,9 @@
2.126
2.127 will cause the echo server application to @code{Start} (enable itself) at one
2.128 second into the simulation and to @code{Stop} (disable itself) at ten seconds
2.129 -into the simulation. By virtue of the fact that we have implicilty declared
2.130 -a simulation event (the application stop event) to be executed at ten seconds,
2.131 -the simulation will last at least ten seconds.
2.132 +into the simulation. By virtue of the fact that we have declared a simulation
2.133 +event (the application stop event) to be executed at ten seconds, the simulation
2.134 +will last @emph{at least} ten seconds.
2.135
2.136 @subsubsection UdpEchoClientHelper
2.137
2.138 @@ -682,25 +692,27 @@
2.139 @end verbatim
2.140
2.141 we actually scheduled events in the simulator at 1.0 seconds, 2.0 seconds and
2.142 -10.0 seconds. When @code{Simulator::Run} is called, the system will begin
2.143 -looking through the list of scheduled events and executing them. First it
2.144 -will run the event at 1.0 seconds, which will enable the echo server
2.145 -application. Then it will run the event scheduled for t=2.0 seconds which
2.146 -will start the echo client application. The start event implementation in
2.147 -the echo client application will begin the data transfer phase of the
2.148 -simulation by sending a packet to the server.
2.149 +two events at 10.0 seconds. When @code{Simulator::Run} is called, the system
2.150 +will begin looking through the list of scheduled events and executing them.
2.151 +First it will run the event at 1.0 seconds, which will enable the echo server
2.152 +application (this event may, in turn, schedule many other events). Then it
2.153 +will run the event scheduled for t=2.0 seconds which will start the echo client
2.154 +application. Again, this event may schedule many more events. The start event
2.155 +implementation in the echo client application will begin the data transfer phase
2.156 +of the simulation by sending a packet to the server.
2.157
2.158 The act of sending the packet to the server will trigger a chain of events
2.159 that will be automatically scheduled behind the scenes and which will perform
2.160 the mechanics of the packet echo according to the various timing parameters
2.161 that we have set in the script.
2.162
2.163 -Eventually, since we only send one packet, the chain of events triggered by
2.164 +Eventually, since we only send one packet (recall the @code{MaxPackets}
2.165 +@code{Attribute} was set to one), the chain of events triggered by
2.166 that single client echo request will taper off and the simulation will go
2.167 idle. Once this happens, the remaining events will be the @code{Stop} events
2.168 for the server and the client. When these events are executed, there are
2.169 no further events to process and @code{Simulator::Run} returns. The simulation
2.170 -is complete.
2.171 +is then complete.
2.172
2.173 All that remains is to clean up. This is done by calling the global function
2.174 @code{Simulator::Destroy}. As the helper functions (or low level
2.175 @@ -721,10 +733,11 @@
2.176 We have made it trivial to build your simple scripts. All you have to do is
2.177 to drop your script into the scratch directory and it will automatically be
2.178 built if you run Waf. Let's try it. Copy @code{examples/first.cc} into
2.179 -the @code{scratch} directory.
2.180 +the @code{scratch} directory after changing back into the top level directory.
2.181
2.182 @verbatim
2.183 - ~/repos/ns-3-dev > cp examples/first.cc scratch/myfirst.cc
2.184 + cd ..
2.185 + cp examples/first.cc scratch/myfirst.cc
2.186 @end verbatim
2.187
2.188 Now build your first example script using waf:
2.189 @@ -737,10 +750,11 @@
2.190 successfully.
2.191
2.192 @verbatim
2.193 - Entering directory `repos/ns-3-allinone-dev/ns-3-dev/build'
2.194 - [563/648] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
2.195 - [646/648] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
2.196 - Build finished successfully (00:00:02)
2.197 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
2.198 + [614/708] cxx: scratch/myfirst.cc -> build/debug/scratch/myfirst_3.o
2.199 + [706/708] cxx_link: build/debug/scratch/myfirst_3.o -> build/debug/scratch/myfirst
2.200 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
2.201 + 'build' finished successfully (2.357s)
2.202 @end verbatim
2.203
2.204 You can now run the example (note that if you build your program in the scratch
2.205 @@ -753,8 +767,9 @@
2.206 You should see some output:
2.207
2.208 @verbatim
2.209 - Entering directory `repos/ns-3-allinone-dev/ns-3-dev/build'
2.210 - Build finished successfully (00:00:00)
2.211 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
2.212 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
2.213 + 'build' finished successfully (0.418s)
2.214 Sent 1024 bytes to 10.1.1.2
2.215 Received 1024 bytes from 10.1.1.1
2.216 Received 1024 bytes from 10.1.1.2
2.217 @@ -778,49 +793,57 @@
2.218 Now that you have used some of the @command{ns-3} helpers you may want to
2.219 have a look at some of the source code that implements that functionality.
2.220 The most recent code can be browsed on our web server at the following link:
2.221 -@uref{http://code.nsnam.org/?sort=lastchange}. If you click on the bold
2.222 -repository names on the left of the page, you will see @emph{changelogs} for
2.223 -these repositories, and links to the @emph{manifest}. From the manifest
2.224 -links, one can browse the source tree.
2.225 +@uref{http://code.nsnam.org/ns-3-dev}. There, you will see the Mercurial
2.226 +summary page for our @command{ns-3} development tree.
2.227
2.228 -The top-level directory for one of our @emph{repositories} will look
2.229 -something like:
2.230 +At the top of the page, you will see a number of links,
2.231
2.232 @verbatim
2.233 -drwxr-xr-x [up]
2.234 -drwxr-xr-x bindings python files
2.235 -drwxr-xr-x doc files
2.236 -drwxr-xr-x examples files
2.237 -drwxr-xr-x ns3 files
2.238 -drwxr-xr-x regression files
2.239 -drwxr-xr-x samples files
2.240 -drwxr-xr-x scratch files
2.241 -drwxr-xr-x src files
2.242 -drwxr-xr-x utils files
2.243 --rw-r--r-- 2009-03-24 00:51 -0700 505 .hgignore file | revisions | annotate
2.244 --rw-r--r-- 2009-03-24 00:51 -0700 1682 .hgtags file | revisions | annotate
2.245 --rw-r--r-- 2009-03-24 00:51 -0700 686 AUTHORS file | revisions | annotate
2.246 --rw-r--r-- 2009-03-24 00:51 -0700 14893 CHANGES.html file | revisions | annotate
2.247 --rw-r--r-- 2009-03-24 00:51 -0700 17987 LICENSE file | revisions | annotate
2.248 --rw-r--r-- 2009-03-24 00:51 -0700 3742 README file | revisions | annotate
2.249 --rw-r--r-- 2009-03-24 00:51 -0700 13505 RELEASE_NOTES file | revisions | annotate
2.250 --rw-r--r-- 2009-03-24 00:51 -0700 6 VERSION file | revisions | annotate
2.251 --rw-r--r-- 2009-03-24 00:51 -0700 9257 regression.py file | revisions | annotate
2.252 --rwxr-xr-x 2009-03-24 00:51 -0700 81285 waf file | revisions | annotate
2.253 --rwxr-xr-x 2009-03-24 00:51 -0700 28 waf.bat file | revisions | annotate
2.254 --rw-r--r-- 2009-03-24 00:51 -0700 26270 wscript file | revisions | annotate
2.255 --rw-r--r-- 2009-03-24 00:51 -0700 6636 wutils.py file | revisions | annotate
2.256 + summary | shortlog | changelog | graph | tags | files
2.257 @end verbatim
2.258
2.259 +Go ahead and select the @code{files} link. This is what the top-level of
2.260 +most of our @emph{repositories} will look:
2.261 +
2.262 +@verbatim
2.263 +drwxr-xr-x [up]
2.264 +drwxr-xr-x bindings python files
2.265 +drwxr-xr-x doc files
2.266 +drwxr-xr-x examples files
2.267 +drwxr-xr-x ns3 files
2.268 +drwxr-xr-x regression files
2.269 +drwxr-xr-x samples files
2.270 +drwxr-xr-x scratch files
2.271 +drwxr-xr-x src files
2.272 +drwxr-xr-x utils files
2.273 +-rw-r--r-- 2009-07-01 12:47 +0200 560 .hgignore file | revisions | annotate
2.274 +-rw-r--r-- 2009-07-01 12:47 +0200 1886 .hgtags file | revisions | annotate
2.275 +-rw-r--r-- 2009-07-01 12:47 +0200 1276 AUTHORS file | revisions | annotate
2.276 +-rw-r--r-- 2009-07-01 12:47 +0200 30961 CHANGES.html file | revisions | annotate
2.277 +-rw-r--r-- 2009-07-01 12:47 +0200 17987 LICENSE file | revisions | annotate
2.278 +-rw-r--r-- 2009-07-01 12:47 +0200 3742 README file | revisions | annotate
2.279 +-rw-r--r-- 2009-07-01 12:47 +0200 16171 RELEASE_NOTES file | revisions | annotate
2.280 +-rw-r--r-- 2009-07-01 12:47 +0200 6 VERSION file | revisions | annotate
2.281 +-rw-r--r-- 2009-07-01 12:47 +0200 10946 regression.py file | revisions | annotate
2.282 +-rwxr-xr-x 2009-07-01 12:47 +0200 88110 waf file | revisions | annotate
2.283 +-rwxr-xr-x 2009-07-01 12:47 +0200 28 waf.bat file | revisions | annotate
2.284 +-rw-r--r-- 2009-07-01 12:47 +0200 35395 wscript file | revisions | annotate
2.285 +-rw-r--r-- 2009-07-01 12:47 +0200 7673 wutils.py file | revisions | annotate
2.286 +@end verbatim
2.287 +
2.288 +Our example scripts are in the @code{examples} directory. If you click on @code{examples}
2.289 +you will see a list of files. One of the files in that directory is @code{first.cc}. If
2.290 +you click on @code{first.cc} you will find the code you just walked through.
2.291 +
2.292 The source code is mainly in the @code{src} directory. You can view source
2.293 code either by clicking on the directory name or by clicking on the @code{files}
2.294 link to the right of the directory name. If you click on the @code{src}
2.295 directory, you will be taken to the listing of the @code{src} subdirectories. If you
2.296 -click on @code{core} subdirectory, you will find a list of files. The first file
2.297 -you will find (as of this writing) is @code{abort.h}. If you
2.298 -click on @code{abort.h} link, you will be sent to the source file for @code{abort.h}.
2.299 +then click on @code{core} subdirectory, you will find a list of files. The first file
2.300 +you will find (as of this writing) is @code{abort.h}. If you click on the
2.301 +@code{abort.h} link, you will be sent to the source file for @code{abort.h} which
2.302 +contains useful macros for exiting scripts if abnormal conditions are detected.
2.303
2.304 -Our example scripts are in the @code{examples} directory. The source code for
2.305 -the helpers we have used in this chapter can be found in the
2.306 +The source code for the helpers we have used in this chapter can be found in the
2.307 @code{src/helper} directory. Feel free to poke around in the directory tree to
2.308 get a feel for what is there and the style of @command{ns-3} programs.
3.1 --- a/doc/tutorial/getting-started.texi Wed Jul 01 12:47:40 2009 +0200
3.2 +++ b/doc/tutorial/getting-started.texi Wed Jul 01 23:08:07 2009 -0700
3.3 @@ -80,7 +80,7 @@
3.4 adding changesets
3.5 adding manifests
3.6 adding file changes
3.7 - added 26 changesets with 40 changes to 7 files
3.8 + added 31 changesets with 45 changes to 7 files
3.9 7 files updated, 0 files merged, 0 files removed, 0 files unresolved
3.10 @end verbatim
3.11
3.12 @@ -126,8 +126,8 @@
3.13
3.14 Since the release numbers are going to be changing, I will stick with
3.15 the more constant ns-3-dev here in the tutorial, but you can replace the
3.16 -string ``ns-3-dev'' with your choice of release (e.g., ns-3.4 and
3.17 -ns-3.4-ref-traces) in the text below. You can find the latest version of the
3.18 +string ``ns-3-dev'' with your choice of release (e.g., ns-3.5 and
3.19 +ns-3.5-ref-traces) in the text below. You can find the latest version of the
3.20 code either by inspection of the repository list or by going to the
3.21 @uref{http://www.nsnam.org/getting_started.html,,``Getting Started''}
3.22 web page and looking for the latest release identifier.
3.23 @@ -138,13 +138,23 @@
3.24
3.25 Go ahead and type the following into your shell (remember you can substitute
3.26 the name of your chosen release number instead of @code{ns-3-dev} -- like
3.27 -@code{"ns-3.4"} and @code{"ns-3.4-ref-traces"} if you want to work with a
3.28 +@code{"ns-3.5"} and @code{"ns-3.5-ref-traces"} if you want to work with a
3.29 stable release).
3.30
3.31 @verbatim
3.32 ./download.py -n ns-3-dev -r ns-3-dev-ref-traces
3.33 @end verbatim
3.34
3.35 +Note that the default for the @code{-n} option is @code{ns-3-dev} and the
3.36 +default for the @code{-r} option is @code{ns-3-dev-ref-traces} and so the
3.37 +above is actually redundant. We provide this example to illustrate how to
3.38 +specify alternate repositories. In order to download @code{ns-3-dev} you
3.39 +can actually use the defaults and simply type,
3.40 +
3.41 +@verbatim
3.42 + ./download.py
3.43 +@end verbatim
3.44 +
3.45 As the hg (Mercurial) command executes, you should see something like the
3.46 following,
3.47
3.48 @@ -152,15 +162,15 @@
3.49 #
3.50 # Get NS-3
3.51 #
3.52 -
3.53 +
3.54 Cloning ns-3 branch
3.55 => hg clone http://code.nsnam.org/ns-3-dev ns-3-dev
3.56 requesting all changes
3.57 adding changesets
3.58 adding manifests
3.59 adding file changes
3.60 - added 4292 changesets with 15368 changes to 1671 files
3.61 - 823 files updated, 0 files merged, 0 files removed, 0 files unresolved
3.62 + added 4634 changesets with 16500 changes to 1762 files
3.63 + 870 files updated, 0 files merged, 0 files removed, 0 files unresolved
3.64 @end verbatim
3.65
3.66 This is output by the download script as it fetches the actual @code{ns-3}
3.67 @@ -177,8 +187,8 @@
3.68 adding changesets
3.69 adding manifests
3.70 adding file changes
3.71 - added 79 changesets with 1102 changes to 222 files
3.72 - 206 files updated, 0 files merged, 0 files removed, 0 files unresolved
3.73 + added 86 changesets with 1178 changes to 259 files
3.74 + 208 files updated, 0 files merged, 0 files removed, 0 files unresolved
3.75 @end verbatim
3.76
3.77 This is the download script fetching the reference trace files for you.
3.78 @@ -191,10 +201,10 @@
3.79 #
3.80 # Get PyBindGen
3.81 #
3.82 -
3.83 - Required pybindgen version: 0.10.0.630
3.84 +
3.85 + Required pybindgen version: 0.10.0.640
3.86 Trying to fetch pybindgen; this will fail if no network connection is available. Hit Ctrl-C to skip.
3.87 - => bzr checkout -rrevno:630 https://launchpad.net/pybindgen pybindgen
3.88 + => bzr checkout -rrevno:640 https://launchpad.net/pybindgen pybindgen
3.89 Fetch was successful.
3.90 @end verbatim
3.91
3.92 @@ -205,7 +215,7 @@
3.93 #
3.94 # Get NSC
3.95 #
3.96 -
3.97 +
3.98 Required NSC version: nsc-0.5.0
3.99 Retrieving nsc from https://secure.wand.net.nz/mercurial/nsc
3.100 => hg clone https://secure.wand.net.nz/mercurial/nsc nsc
3.101 @@ -213,8 +223,8 @@
3.102 adding changesets
3.103 adding manifests
3.104 adding file changes
3.105 - added 270 changesets with 17375 changes to 14991 files
3.106 - 10614 files updated, 0 files merged, 0 files removed, 0 files unresolved
3.107 + added 273 changesets with 17565 changes to 15175 files
3.108 + 10622 files updated, 0 files merged, 0 files removed, 0 files unresolved
3.109 @end verbatim
3.110
3.111 This part of the process is the script downloading the Network Simulation
3.112 @@ -257,16 +267,16 @@
3.113 cd
3.114 mkdir tarballs
3.115 cd tarballs
3.116 - wget http://www.nsnam.org/releases/ns-allinone-3.4.tar.bz2
3.117 - tar xjf ns-allinone-3.4.tar.bz2
3.118 + wget http://www.nsnam.org/releases/ns-allinone-3.5.tar.bz2
3.119 + tar xjf ns-allinone-3.5.tar.bz2
3.120 @end verbatim
3.121
3.122 -If you change into the directory @code{ns-allinone-3.4} you should see a
3.123 +If you change into the directory @code{ns-allinone-3.5} you should see a
3.124 number of files:
3.125
3.126 @verbatim
3.127 -build.py* ns-3.4/ nsc-0.5.0/ README
3.128 -constants.py ns-3.4-ref-traces/ pybindgen-0.10.0.630/ util.py
3.129 +build.py* ns-3.5/ nsc-0.5.0/ README
3.130 +constants.py ns-3.5-ref-traces/ pybindgen-0.10.0.640/ util.py
3.131 @end verbatim
3.132
3.133 You are now ready to build the @command{ns-3} distribution.
3.134 @@ -288,7 +298,7 @@
3.135 downloaded using Mercurial you should have a directory called
3.136 @code{ns-3-allinone} under your @code{~/repos} directory. If you downloaded
3.137 using a tarball you should have a directory called something like
3.138 -@code{ns-3-allinone-3.4} under your @code{~/tarballs} directory. Take a deep
3.139 +@code{ns-allinone-3.5} under your @code{~/tarballs} directory. Take a deep
3.140 breath and type the following:
3.141
3.142 @verbatim
3.143 @@ -300,13 +310,13 @@
3.144 following magic words:
3.145
3.146 @verbatim
3.147 - Build finished successfully (00:02:37)
3.148 - Leaving directory `./ns-3-dev'
3.149 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
3.150 + 'build' finished successfully (2m30.586s)
3.151 @end verbatim
3.152
3.153 Once the project has built you can say goodbye to your old friends, the
3.154 @code{ns-3-allinone} scripts. You got what you needed from them and will now
3.155 -interact directly with Waf and we do it in the @code{ns-3-dev} directory and
3.156 +interact directly with Waf and we do it in the @code{ns-3-dev} directory,
3.157 not in the @code{ns-3-allinone} directory. Go ahead and change into the
3.158 @code{ns-3-dev} directory (or the directory for the appropriate release you
3.159 downloaded.
3.160 @@ -340,76 +350,72 @@
3.161 output that looks similar to the following,
3.162
3.163 @verbatim
3.164 -Checking for program g++ : ok /usr/bin/g++
3.165 -Checking for program cpp : ok /usr/bin/cpp
3.166 -Checking for program ar : ok /usr/bin/ar
3.167 -Checking for program ranlib : ok /usr/bin/ranlib
3.168 -Checking for g++ : ok
3.169 -Checking for program pkg-config : ok /usr/bin/pkg-config
3.170 -Checking for regression reference traces : ok ../ns-3-dev-ref-traces (guessed)
3.171 -Checking for -Wno-error=deprecated-declarations support : yes
3.172 -Checking for header stdlib.h : ok
3.173 -Checking for header signal.h : ok
3.174 -Checking for header pthread.h : ok
3.175 -Checking for high precision time implementation : 128-bit integer
3.176 -Checking for header stdint.h : ok
3.177 -Checking for header inttypes.h : ok
3.178 -Checking for header sys/inttypes.h : not found
3.179 -Checking for library rt : ok
3.180 -Checking for header netpacket/packet.h : ok
3.181 -Checking for header linux/if_tun.h : ok
3.182 -Checking for pkg-config flags for GTK_CONFIG_STORE : ok
3.183 -Package libxml-2.0 was not found in the pkg-config search path.
3.184 -Perhaps you should add the directory containing `libxml-2.0.pc'
3.185 -to the PKG_CONFIG_PATH environment variable
3.186 -No package 'libxml-2.0' found
3.187 -Checking for pkg-config flags for LIBXML2 : not found
3.188 -Checking for library sqlite3 : ok
3.189 -Checking for NSC location : ok ../nsc (guessed)
3.190 -Checking for library dl : ok
3.191 -Checking for NSC supported architecture x86_64 : ok
3.192 -Package goocanvas was not found in the pkg-config search path.
3.193 -Perhaps you should add the directory containing `goocanvas.pc'
3.194 -to the PKG_CONFIG_PATH environment variable
3.195 -No package 'goocanvas' found
3.196 -Checking for pkg-config flags for MOBILITY_VISUALIZER : not found
3.197 -Checking for program python : ok /usr/bin/python
3.198 -Checking for Python version >= 2.3 : ok 2.5.2
3.199 -Checking for library python2.5 : ok
3.200 -Checking for program python2.5-config : ok /usr/bin/python2.5-config
3.201 -Checking for header Python.h : ok
3.202 -Checking for -fvisibility=hidden support : yes
3.203 -Checking for pybindgen location : ok ../pybindgen (guessed)
3.204 -Checking for Python module pybindgen : ok
3.205 -Checking for pybindgen version : ok 0.10.0.630
3.206 -Checking for Python module pygccxml : ok
3.207 -Checking for pygccxml version : ok 0.9.5
3.208 -Checking for program gccxml : ok /usr/local/bin/gccxml
3.209 -Checking for gccxml version : ok 0.9.0
3.210 -Checking for program sudo : ok /usr/bin/sudo
3.211 -Checking for program hg : ok /usr/bin/hg
3.212 -Checking for program valgrind : ok /usr/bin/valgrind
3.213 ----- Summary of optional NS-3 features:
3.214 -Threading Primitives : enabled
3.215 -Real Time Simulator : enabled
3.216 -Emulated Net Device : enabled
3.217 -Tap Bridge : enabled
3.218 -GtkConfigStore : enabled
3.219 -XmlIo : not enabled (library 'libxml-2.0 >= 2.7' not found)
3.220 -SQlite stats data output : enabled
3.221 -Network Simulation Cradle : enabled
3.222 -Python Bindings : enabled
3.223 -Python API Scanning Support : enabled
3.224 -Use sudo to set suid bit : not enabled (option --enable-sudo not selected)
3.225 -Configuration finished successfully (00:00:02); project is now ready to build.
3.226 + Checking for program g++ : ok /usr/bin/g++
3.227 + Checking for program cpp : ok /usr/bin/cpp
3.228 + Checking for program ar : ok /usr/bin/ar
3.229 + Checking for program ranlib : ok /usr/bin/ranlib
3.230 + Checking for g++ : ok
3.231 + Checking for program pkg-config : ok /usr/bin/pkg-config
3.232 + Checking for regression reference traces : ok ../ns-3-dev-ref-traces (guessed)
3.233 + Checking for -Wno-error=deprecated-declarations support : yes
3.234 + Checking for -Wl,--soname=foo support : yes
3.235 + Checking for header stdlib.h : ok
3.236 + Checking for header signal.h : ok
3.237 + Checking for header pthread.h : ok
3.238 + Checking for high precision time implementation : 128-bit integer
3.239 + Checking for header stdint.h : ok
3.240 + Checking for header inttypes.h : ok
3.241 + Checking for header sys/inttypes.h : not found
3.242 + Checking for library rt : ok
3.243 + Checking for header netpacket/packet.h : ok
3.244 + Checking for pkg-config flags for GSL : ok
3.245 + Checking for header linux/if_tun.h : ok
3.246 + Checking for pkg-config flags for GTK_CONFIG_STORE : ok
3.247 + Checking for pkg-config flags for LIBXML2 : ok
3.248 + Checking for library sqlite3 : ok
3.249 + Checking for NSC location : ok ../nsc (guessed)
3.250 + Checking for library dl : ok
3.251 + Checking for NSC supported architecture x86_64 : ok
3.252 + Checking for program python : ok /usr/bin/python
3.253 + Checking for Python version >= 2.3 : ok 2.5.2
3.254 + Checking for library python2.5 : ok
3.255 + Checking for program python2.5-config : ok /usr/bin/python2.5-config
3.256 + Checking for header Python.h : ok
3.257 + Checking for -fvisibility=hidden support : yes
3.258 + Checking for pybindgen location : ok ../pybindgen (guessed)
3.259 + Checking for Python module pybindgen : ok
3.260 + Checking for pybindgen version : ok 0.10.0.640
3.261 + Checking for Python module pygccxml : ok
3.262 + Checking for pygccxml version : ok 0.9.5
3.263 + Checking for program gccxml : ok /usr/local/bin/gccxml
3.264 + Checking for gccxml version : ok 0.9.0
3.265 + Checking for program sudo : ok /usr/bin/sudo
3.266 + Checking for program hg : ok /usr/bin/hg
3.267 + Checking for program valgrind : ok /usr/bin/valgrind
3.268 + ---- Summary of optional NS-3 features:
3.269 + Threading Primitives : enabled
3.270 + Real Time Simulator : enabled
3.271 + Emulated Net Device : enabled
3.272 + GNU Scientific Library (GSL) : enabled
3.273 + Tap Bridge : enabled
3.274 + GtkConfigStore : enabled
3.275 + XmlIo : enabled
3.276 + SQlite stats data output : enabled
3.277 + Network Simulation Cradle : enabled
3.278 + Python Bindings : enabled
3.279 + Python API Scanning Support : enabled
3.280 + Use sudo to set suid bit : not enabled (option --enable-sudo not selected)
3.281 + Static build : not enabled (option --enable-static not selected)
3.282 + 'configure' finished successfully (2.870s)
3.283 @end verbatim
3.284
3.285 Note the last part of the above output. Some ns-3 options are not enabled by
3.286 default or require support from the underlying system to work properly.
3.287 For instance, to enable XmlTo, the library libxml-2.0 must be found on the
3.288 -system. in the example above, this library was not found and the corresponding
3.289 -feature was not enabled. There is a feature to use sudo to set the suid bit of
3.290 -certain programs. This was not enabled by default.
3.291 +system. If this library were not found, the corresponding @command{ns-3} feature
3.292 +would not be enabled and a message would be displayed. Note further that there is
3.293 +a feature to use the progarm @code{sudo} to set the suid bit of certain programs.
3.294 +This is not enabled by default and so this feature is reported as ``not enabled.''
3.295
3.296 Now go ahead and switch back to the debug build.
3.297
3.298 @@ -427,15 +433,15 @@
3.299 Some waf commands are meaningful during the build phase and some commands are valid
3.300 in the configuration phase. For example, if you wanted to use the emulation
3.301 features of @command{ns-3} you might want to enable setting the suid bit using
3.302 -sudo. This is a configuration command, and so you could have run the following
3.303 -command
3.304 +sudo as described above. This turns out to be a configuration-time command, and so
3.305 +you could reconfigure using the following command
3.306
3.307 @verbatim
3.308 ./waf -d debug --enable-sudo configure
3.309 @end verbatim
3.310
3.311 -If you had done this, waf would have run sudo to change the socket creator
3.312 -programs to run as root. There are many other configure- and build-time options
3.313 +If you do this, waf will have run sudo to change the socket creator programs of the
3.314 +emulation code to run as root. There are many other configure- and build-time options
3.315 available in waf. To explore these options, type:
3.316
3.317 @verbatim
3.318 @@ -462,26 +468,45 @@
3.319 ./waf --check
3.320 @end verbatim
3.321
3.322 -You should see a report from each unit test that executes indicating that the
3.323 -test has passed.
3.324 +These tests are run in parallel by waf, so the summary, ``Ran n tests'' will
3.325 +appear as soon as all of the tasks are launched, but you should eventually
3.326 +see a report saying that,
3.327
3.328 @verbatim
3.329 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
3.330 - Build finished successfully (00:00:00)
3.331 - -- Running NS-3 C++ core unit tests...
3.332 - PASS AddressHelper
3.333 - PASS Wifi
3.334 - PASS DcfManager
3.335 - ...
3.336 - PASS Object
3.337 - PASS Ptr
3.338 - PASS Callback
3.339 - -- Running NS-3 Python bindings unit tests...
3.340 + C++ UNIT TESTS: all 33 tests passed.
3.341 +@end verbatim
3.342 +
3.343 +This is the important message.
3.344 +
3.345 +You will also see output from the test runner and waf task sequence numbers
3.346 +the output will actually look something like,
3.347 +
3.348 +@verbatim
3.349 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
3.350 + [707/709] get-unit-tests-list
3.351 + [708/709] run-python-unit-tests
3.352 + [709/709] print-introspected-doxygen
3.353 + [710/743] run-unit-test(AddressHelper)
3.354 + [711/743] run-unit-test(Wifi)
3.355 ...........
3.356 ----------------------------------------------------------------------
3.357 Ran 11 tests in 0.003s
3.358 +
3.359 + OK
3.360 + [712/743] run-unit-test(DcfManager)
3.361 + [713/743] run-unit-test(MacRxMiddle)
3.362 + [714/743] run-unit-test(Ipv4ListRouting)
3.363
3.364 - OK
3.365 + ...
3.366 +
3.367 + [739/743] run-unit-test(RandomVariable)
3.368 + [740/743] run-unit-test(Object)
3.369 + [741/743] run-unit-test(Ptr)
3.370 + [742/743] run-unit-test(Callback)
3.371 + [743/743] collect-unit-tests-results
3.372 + C++ UNIT TESTS: all 33 tests passed.
3.373 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
3.374 + 'build' finished successfully (1.799s)
3.375 @end verbatim
3.376
3.377 This command is typically run by @code{users} to quickly verify that an
3.378 @@ -491,10 +516,10 @@
3.379 You can also run our regression test suite to ensure that your distribution and
3.380 toolchain have produced binaries that generate output that is identical to
3.381 known-good reference output files. You downloaded these reference traces to
3.382 -your machine during the download process above. (Warning: The @code{ns-3.2}
3.383 -and @code{ns-3.3} releases do not use the @code{ns-3-allinone} environment
3.384 -and require you to be online when you run regression tests because they
3.385 -dynamically synchronize the reference traces directory with an online
3.386 +your machine during the @code{./download.py} process above. (Warning: The
3.387 +@code{ns-3.2} and @code{ns-3.3} releases do not use the @code{ns-3-allinone}
3.388 +environment and require you to be online when you run regression tests because
3.389 +hey dynamically synchronize the reference traces directory with an online
3.390 repository immediately prior to the run).
3.391
3.392 During regression testing Waf will run a number of tests that generate what we
3.393 @@ -509,6 +534,9 @@
3.394 Some regression tests may be SKIPped if the required support
3.395 is not present.
3.396
3.397 +Note that the regression tests are also run in parallel and so the messages
3.398 +may be interleaved.
3.399 +
3.400 To run the regression tests, you provide Waf with the regression flag.
3.401
3.402 @verbatim
3.403 @@ -530,7 +558,8 @@
3.404 ...
3.405 Regression testing summary:
3.406 PASS: 22 of 22 tests passed
3.407 - Build finished successfully (00:00:23)
3.408 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
3.409 + 'build' finished successfully (25.826s)
3.410 @end verbatim
3.411
3.412 If you want to take a look at an example of what might be checked during
4.1 --- a/doc/tutorial/introduction.texi Wed Jul 01 12:47:40 2009 +0200
4.2 +++ b/doc/tutorial/introduction.texi Wed Jul 01 23:08:07 2009 -0700
4.3 @@ -75,7 +75,7 @@
4.4 generates pcap packet trace files, other utilities can be used to
4.5 analyze traces as well.
4.6 In this tutorial, we will first concentrate on scripting
4.7 -directly in C++ and interpreting results via ascii trace files.
4.8 +directly in C++ and interpreting results via trace files.
4.9
4.10 But there are similarities as well (both, for example, are based on C++
4.11 objects, and some code from ns-2 has already been ported to @command{ns-3}).
4.12 @@ -256,8 +256,8 @@
4.13 software toolchain is the set of programming tools available in the given
4.14 environment. For a quick review of what is included in the GNU toolchain see,
4.15 @uref{http://en.wikipedia.org/wiki/GNU_toolchain}. @command{ns-3} uses gcc,
4.16 -GNU binutils, and gdb. However, we do not use the GNU build system,
4.17 -either make or autotools, using Waf instead.
4.18 +GNU binutils, and gdb. However, we do not use the GNU build system tools,
4.19 +neither make nor autotools. We use Waf for these functions.
4.20
4.21 @cindex Linux
4.22 Typically an @command{ns-3} author will work in Linux or a Linux-like
4.23 @@ -265,11 +265,11 @@
4.24 which simulate the Linux environment to various degrees. The @command{ns-3}
4.25 project supports development in the Cygwin environment for
4.26 these users. See @uref{http://www.cygwin.com/}
4.27 -for details on downloading (MinGW is presently not supported).
4.28 -Cygwin provides many of the popular Linux system commands.
4.29 -It can, however, sometimes be problematic due to the way it actually does its
4.30 -emulation, and sometimes interactions with other Windows software can cause
4.31 -problems.
4.32 +for details on downloading (MinGW is presently not officially supported,
4.33 +although some of the project maintainers to work with it). Cygwin provides
4.34 +many of the popular Linux system commands. It can, however, sometimes be
4.35 +problematic due to the way it actually does its emulation, and sometimes
4.36 +interactions with other Windows software can cause problems.
4.37
4.38 @cindex Cygwin
4.39 @cindex MinGW
5.1 --- a/doc/tutorial/tweaking.texi Wed Jul 01 12:47:40 2009 +0200
5.2 +++ b/doc/tutorial/tweaking.texi Wed Jul 01 23:08:07 2009 -0700
5.3 @@ -89,7 +89,8 @@
5.4 @subsection Enabling Logging
5.5 @cindex NS_LOG
5.6 Let's use the NS_LOG environment variable to turn on some more logging, but
5.7 -to get our bearings, go ahead and run the script just as you did previously,
5.8 +first, just to get our bearings, go ahead and run the last script just as you
5.9 +did previously,
5.10
5.11 @verbatim
5.12 ./waf --run scratch/myfirst
5.13 @@ -99,8 +100,9 @@
5.14 program
5.15
5.16 @verbatim
5.17 - Entering directory `repos/ns-3-dev/build'
5.18 - Compilation finished successfully
5.19 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.20 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.21 + 'build' finished successfully (0.413s)
5.22 Sent 1024 bytes to 10.1.1.2
5.23 Received 1024 bytes from 10.1.1.1
5.24 Received 1024 bytes from 10.1.1.2
5.25 @@ -148,15 +150,17 @@
5.26 system will pick up the change and you should see the following output:
5.27
5.28 @verbatim
5.29 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.30 - Build finished successfully (00:00:00)
5.31 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build
5.32 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.33 + 'build' finished successfully (0.404s)
5.34 UdpEchoClientApplication:UdpEchoClient()
5.35 + UdpEchoClientApplication:SetDataSize(1024)
5.36 UdpEchoClientApplication:StartApplication()
5.37 UdpEchoClientApplication:ScheduleTransmit()
5.38 UdpEchoClientApplication:Send()
5.39 Sent 1024 bytes to 10.1.1.2
5.40 Received 1024 bytes from 10.1.1.1
5.41 - UdpEchoClientApplication:HandleRead(0x638180, 0x6389b0)
5.42 + UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
5.43 Received 1024 bytes from 10.1.1.2
5.44 UdpEchoClientApplication:StopApplication()
5.45 UdpEchoClientApplication:DoDispose()
5.46 @@ -186,7 +190,7 @@
5.47 It turns out that in some cases, it can be hard to determine which method
5.48 actually generates a log message. If you look in the text above, you may
5.49 wonder where the string ``@code{Received 1024 bytes from 10.1.1.2}'' comes
5.50 -from. You can resolve this by ORing the @code{prefix_func} level into the
5.51 +from. You can resolve this by OR'ing the @code{prefix_func} level into the
5.52 @code{NS_LOG} environment variable. Try doing the following,
5.53
5.54 @verbatim
5.55 @@ -201,15 +205,17 @@
5.56 name.
5.57
5.58 @verbatim
5.59 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.60 - Build finished successfully (00:00:00)
5.61 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.62 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.63 + 'build' finished successfully (0.417s)
5.64 UdpEchoClientApplication:UdpEchoClient()
5.65 + UdpEchoClientApplication:SetDataSize(1024)
5.66 UdpEchoClientApplication:StartApplication()
5.67 UdpEchoClientApplication:ScheduleTransmit()
5.68 UdpEchoClientApplication:Send()
5.69 UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
5.70 Received 1024 bytes from 10.1.1.1
5.71 - UdpEchoClientApplication:HandleRead(0x638180, 0x6389b0)
5.72 + UdpEchoClientApplication:HandleRead(0x6241e0, 0x624a20)
5.73 UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
5.74 UdpEchoClientApplication:StopApplication()
5.75 UdpEchoClientApplication:DoDispose()
5.76 @@ -236,10 +242,12 @@
5.77 in debugging problems.
5.78
5.79 @verbatim
5.80 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.81 - Build finished successfully (00:00:00)
5.82 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.83 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.84 + 'build' finished successfully (0.406s)
5.85 UdpEchoServerApplication:UdpEchoServer()
5.86 UdpEchoClientApplication:UdpEchoClient()
5.87 + UdpEchoClientApplication:SetDataSize(1024)
5.88 UdpEchoServerApplication:StartApplication()
5.89 UdpEchoClientApplication:StartApplication()
5.90 UdpEchoClientApplication:ScheduleTransmit()
5.91 @@ -247,7 +255,7 @@
5.92 UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
5.93 UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
5.94 UdpEchoServerApplication:HandleRead(): Echoing packet
5.95 - UdpEchoClientApplication:HandleRead(0x638320, 0x638b50)
5.96 + UdpEchoClientApplication:HandleRead(0x624920, 0x625160)
5.97 UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
5.98 UdpEchoServerApplication:StopApplication()
5.99 UdpEchoClientApplication:StopApplication()
5.100 @@ -269,10 +277,12 @@
5.101 you should see the following output:
5.102
5.103 @verbatim
5.104 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.105 - Build finished successfully (00:00:00)
5.106 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.107 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.108 + 'build' finished successfully (0.418s)
5.109 0s UdpEchoServerApplication:UdpEchoServer()
5.110 0s UdpEchoClientApplication:UdpEchoClient()
5.111 + 0s UdpEchoClientApplication:SetDataSize(1024)
5.112 1s UdpEchoServerApplication:StartApplication()
5.113 2s UdpEchoClientApplication:StartApplication()
5.114 2s UdpEchoClientApplication:ScheduleTransmit()
5.115 @@ -280,7 +290,7 @@
5.116 2s UdpEchoClientApplication:Send(): Sent 1024 bytes to 10.1.1.2
5.117 2.00369s UdpEchoServerApplication:HandleRead(): Received 1024 bytes from 10.1.1.1
5.118 2.00369s UdpEchoServerApplication:HandleRead(): Echoing packet
5.119 - 2.00737s UdpEchoClientApplication:HandleRead(0x638490, 0x638cc0)
5.120 + 2.00737s UdpEchoClientApplication:HandleRead(0x624290, 0x624ad0)
5.121 2.00737s UdpEchoClientApplication:HandleRead(): Received 1024 bytes from 10.1.1.2
5.122 10s UdpEchoServerApplication:StopApplication()
5.123 10s UdpEchoClientApplication:StopApplication()
5.124 @@ -292,22 +302,22 @@
5.125
5.126 You can see that the constructor for the UdpEchoServer was called at a
5.127 simulation time of 0 seconds. This is actually happening before the
5.128 -simulation starts. The same for the UdpEchoClient constructor.
5.129 +simulation starts, but the time is displayed as zero seconds. The same is true
5.130 +for the UdpEchoClient constructor message.
5.131
5.132 Recall that the @code{scratch/first.cc} script started the echo server
5.133 application at one second into the simulation. You can now see that the
5.134 -@code{StartApplication} method of the server is, in fact, called at one second
5.135 -(or one billion nanoseconds). You can also see that the echo client
5.136 -application is started at a simulation time of two seconds as we requested in
5.137 -the script.
5.138 +@code{StartApplication} method of the server is, in fact, called at one second.
5.139 +You can also see that the echo client application is started at a simulation
5.140 +time of two seconds as we requested in the script.
5.141
5.142 You can now follow the progress of the simulation from the
5.143 @code{ScheduleTransmit} call in the client that calls @code{Send} to the
5.144 @code{HandleRead} callback in the echo server application. Note that the
5.145 -elapsed time as the packet is sent across the point-to-point link is 3.6864
5.146 +elapsed time for the packet to be sent across the point-to-point link is 3.69
5.147 milliseconds. You see the echo server logging a message telling you that it
5.148 -has echoed the packet and then, after a delay, you see the echo client receive
5.149 -the echoed packet in its @code{HandleRead} method.
5.150 +has echoed the packet and then, after another channel delay, you see the echo
5.151 +client receive the echoed packet in its @code{HandleRead} method.
5.152
5.153 There is a lot that is happening under the covers in this simulation that you
5.154 are not seeing as well. You can very easily follow the entire process by
5.155 @@ -320,7 +330,7 @@
5.156
5.157 The asterisk above is the logging component wildcard. This will turn on all
5.158 of the logging in all of the components used in the simulation. I won't
5.159 -reproduce the output here (as of this writing it produces 974 lines of output
5.160 +reproduce the output here (as of this writing it produces 1265 lines of output
5.161 for the single packet echo) but you can redirect this information into a file
5.162 and look through it with your favorite editor if you like,
5.163
5.164 @@ -328,15 +338,16 @@
5.165 ./waf --run scratch/myfirst > log.out 2>&1
5.166 @end verbatim
5.167
5.168 -I personally use this volume of logging quite a bit when I am presented with
5.169 -a problem and I have no idea where things are going wrong. I can follow the
5.170 +I personally use this extremely verbose version of logging when I am presented
5.171 +with a problem and I have no idea where things are going wrong. I can follow the
5.172 progress of the code quite easily without having to set breakpoints and step
5.173 -through code in a debugger. When I have a general idea about what is going
5.174 -wrong, I transition into a debugger for fine-grained examination of the
5.175 -problem. This kind of output can be especially useful when your script does
5.176 -something completely unexpected. If you are stepping using a debugger you
5.177 -may miss an unexpected excursion completely. Logging the excursion makes it
5.178 -quickly visible.
5.179 +through code in a debugger. I can just edit up the output in my favorite editor
5.180 +and search around for things I expect, and see things happening that I don't
5.181 +expect. When I have a general idea about what is going wrong, I transition into
5.182 +a debugger for a fine-grained examination of the problem. This kind of output
5.183 +can be especially useful when your script does something completely unexpected.
5.184 +If you are stepping using a debugger you may miss an unexpected excursion
5.185 +completely. Logging the excursion makes it quickly visible.
5.186
5.187 @node Adding Logging to your Code
5.188 @subsection Adding Logging to your Code
5.189 @@ -399,8 +410,9 @@
5.190 message,
5.191
5.192 @verbatim
5.193 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.194 - Build finished successfully (00:00:00)
5.195 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.196 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.197 + 'build' finished successfully (0.404s)
5.198 Creating Topology
5.199 Sent 1024 bytes to 10.1.1.2
5.200 Received 1024 bytes from 10.1.1.1
5.201 @@ -453,8 +465,11 @@
5.202 now see the @code{--PrintHelp} argument and respond with,
5.203
5.204 @verbatim
5.205 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.206 - Build finished successfully (00:00:00)
5.207 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.208 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.209 + 'build' finished successfully (0.413s)
5.210 + TcpL4Protocol:TcpStateMachine()
5.211 + CommandLine:HandleArgument(): Handle arg name=PrintHelp value=
5.212 --PrintHelp: Print this help message.
5.213 --PrintGroups: Print the list of groups.
5.214 --PrintTypeIds: Print all TypeIds.
5.215 @@ -527,7 +542,9 @@
5.216 If you run the script, you should now see the following output,
5.217
5.218 @verbatim
5.219 - Build finished successfully (00:00:00)
5.220 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.221 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.222 + 'build' finished successfully (0.405s)
5.223 0s UdpEchoServerApplication:UdpEchoServer()
5.224 1s UdpEchoServerApplication:StartApplication()
5.225 Sent 1024 bytes to 10.1.1.2
5.226 @@ -589,8 +606,9 @@
5.227 @code{DataRate} and @code{Delay} in the script:
5.228
5.229 @verbatim
5.230 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.231 - Build finished successfully (00:00:00)
5.232 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/bu
5.233 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/bui
5.234 + 'build' finished successfully (0.417s)
5.235 0s UdpEchoServerApplication:UdpEchoServer()
5.236 1s UdpEchoServerApplication:StartApplication()
5.237 Sent 1024 bytes to 10.1.1.2
5.238 @@ -608,13 +626,13 @@
5.239 to some other value than one.
5.240
5.241 How would you go about that? Give it a try. Remember you have to comment
5.242 -out the place we override the default @code{Attribute} in the script. Then you
5.243 -have to rebuild the script using the default. You will also have to find the
5.244 -syntax for actually setting the new default atribute value using the command
5.245 -line help facility. Once you have this figured out you should be able to
5.246 -control the number of packets echoed from the command line. Since we're nice
5.247 -folks, we'll tell you that your command line should end up looking something
5.248 -like,
5.249 +out the place we override the default @code{Attribute} and explicitly set
5.250 +@code{MaxPackets} in the script. Then you have to rebuild the script. You
5.251 +will also have to find the syntax for actually setting the new default atribute
5.252 +value using the command line help facility. Once you have this figured out
5.253 +you should be able to control the number of packets echoed from the command
5.254 +line. Since we're nice folks, we'll tell you that your command line should
5.255 +end up looking something like,
5.256
5.257 @verbatim
5.258 ./waf --run "scratch/myfirst
5.259 @@ -666,8 +684,9 @@
5.260 @end verbatim
5.261
5.262 @verbatim
5.263 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.264 - Build finished successfully (00:00:00)
5.265 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.266 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.267 + 'build' finished successfully (0.403s)
5.268 --PrintHelp: Print this help message.
5.269 --PrintGroups: Print the list of groups.
5.270 --PrintTypeIds: Print all TypeIds.
5.271 @@ -688,8 +707,9 @@
5.272 You should now see
5.273
5.274 @verbatim
5.275 - Entering directory `repos/ns-3-allinone/ns-3-dev/build'
5.276 - Build finished successfully (00:00:00)
5.277 + Waf: Entering directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.278 + Waf: Leaving directory `/home/craigdo/repos/ns-3-allinone-3.5-tutorial/ns-3-dev/build'
5.279 + 'build' finished successfully (0.404s)
5.280 0s UdpEchoServerApplication:UdpEchoServer()
5.281 1s UdpEchoServerApplication:StartApplication()
5.282 Sent 1024 bytes to 10.1.1.2
5.283 @@ -705,7 +725,7 @@
5.284 UdpEchoServerApplication:~UdpEchoServer()
5.285 @end verbatim
5.286
5.287 -You have now echoed two packets.
5.288 +You have now echoed two packets. Pretty easy, isn't it?
5.289
5.290 You can see that if you are an @command{ns-3} user, you can use the command
5.291 line argument system to control global values and @code{Attributes}. If you are
5.292 @@ -827,7 +847,7 @@
5.293
5.294 @cindex myfirst.tr
5.295 Just as you have seen many times before, you will see some messages from Waf and then
5.296 -the ``Build finished successfully'' with some number of messages from
5.297 +``'build' finished successfully'' with some number of messages from
5.298 the running program.
5.299
5.300 When it ran, the program will have created a file named @code{myfirst.tr}.