Tutorial spellcheck

doc/tutorial/source/building-topologies.rst

@@ -785,7 +785,7 @@ topology helpers in this section.  The appearance and operation of these
 helpers should look quite familiar to you.
 
 We provide an example script in our ``examples/tutorial`` directory.  This script
-builds on the ``second.cc`` script and adds a Wifi network.  Go ahead and
+builds on the ``second.cc`` script and adds a Wi-Fi network.  Go ahead and
 open ``examples/tutorial/third.cc`` in your favorite editor.  You will have already
 seen enough |ns3| code to understand most of what is going on in 
 this example, but there are a few new things, so we will go over the entire 
@@ -808,7 +808,7 @@ network.  By default there are three "extra" CSMA nodes and three wireless
 
 The code begins by loading module include files just as was done in the
 ``second.cc`` example.  There are a couple of new includes corresponding
-to the Wifi module and the mobility module which we will discuss below.
+to the wifi module and the mobility module which we will discuss below.
 
 ::
 
@@ -925,7 +925,7 @@ selected nodes.
   NetDeviceContainer csmaDevices;
   csmaDevices = csma.Install (csmaNodes);
 
-Next, we are going to create the nodes that will be part of the Wifi network.
+Next, we are going to create the nodes that will be part of the Wi-Fi network.
 We are going to create a number of "station" nodes as specified by the 
 command line argument, and we are going to use the "leftmost" node of the 
 point-to-point link as the node for the access point.
@@ -996,14 +996,14 @@ created by this helper.
 
 Once all the station-specific parameters are fully configured, both at the
 MAC and PHY layers, we can invoke our now-familiar ``Install`` method to 
-create the wifi devices of these stations:
+create the Wi-Fi devices of these stations:
 
 ::
 
   NetDeviceContainer staDevices;
   staDevices = wifi.Install (phy, mac, wifiStaNodes);
 
-We have configured Wifi for all of our STA nodes, and now we need to 
+We have configured Wi-Fi for all of our STA nodes, and now we need to 
 configure the AP (access point) node.  We begin this process by changing
 the default ``Attributes`` of the ``WifiMacHelper`` to reflect the 
 requirements of the AP.
@@ -1076,7 +1076,7 @@ We accomplish this by setting the mobility model for this node to be the
   mobility.Install (wifiApNode);
 
 We now have our nodes, devices and channels created, and mobility models 
-chosen for the Wifi nodes, but we have no protocol stacks present.  Just as 
+chosen for the Wi-Fi nodes, but we have no protocol stacks present.  Just as 
 we have done previously many times, we will use the ``InternetStackHelper``
 to install these stacks.
 
@@ -1166,7 +1166,7 @@ We create just enough tracing to cover all three networks:
 
 These three lines of code will start pcap tracing on both of the point-to-point
 nodes that serves as our backbone, will start a promiscuous (monitor) mode 
-trace on the Wifi network, and will start a promiscuous trace on the CSMA 
+trace on the Wi-Fi network, and will start a promiscuous trace on the CSMA 
 network.  This will let us see all of the traffic with a minimum number of 
 trace files.
 
@@ -1222,11 +1222,11 @@ 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" 
 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
-mode) trace from the Wifi network and the file "third-1-1.pcap" will be the
+mode) trace from the Wi-Fi 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?
 
-Since the echo client is on the Wifi network, let's start there.  Let's take
+Since the echo client is on the Wi-Fi network, let's start there.  Let's take
 a look at the promiscuous (monitor mode) trace we captured on that network.
 
 .. sourcecode:: bash
@@ -1274,7 +1274,7 @@ Again, you should see some familiar looking contents:
   2.008151 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
   2.026758 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
 
-This is the echo packet going from left to right (from Wifi to CSMA) and back
+This is the echo packet going from left to right (from Wi-Fi to CSMA) and back
 again across the point-to-point link.
 
 Now, look at the pcap file of the right side of the point-to-point link,
@@ -1291,7 +1291,7 @@ Again, you should see some familiar looking contents:
   2.011837 IP 10.1.3.3.49153 > 10.1.2.4.9: UDP, length 1024
   2.023072 IP 10.1.2.4.9 > 10.1.3.3.49153: UDP, length 1024
 
-This is also the echo packet going from left to right (from Wifi to CSMA) and 
+This is also the echo packet going from left to right (from Wi-Fi to CSMA) and 
 back again across the point-to-point link with slightly different timings
 as you might expect.
 

doc/tutorial/source/conceptual-overview.rst

@@ -797,7 +797,7 @@ in the first example program will schedule an explicit stop at 11 seconds:
      return 0;
    }
 
-The above wil not actually change the behavior of this program, since
+The above will not actually change the behavior of this program, since
 this particular simulation naturally ends after 10 seconds.  But if you 
 were to change the stop time in the above statement from 11 seconds to 1 
 second, you would notice that the simulation stops before any output is 

doc/tutorial/source/getting-started.rst

@@ -215,7 +215,7 @@ Step into the workspace directory and type the following into your shell::
 
   $ ./bake.py configure -e ns-3.26
 
-Next, we'l ask bake to check whether we have enough tools to download
+Next, we'll ask bake to check whether we have enough tools to download
 various components.  Type::
 
   $ ./bake.py check

doc/tutorial/source/tracing.rst

@@ -1106,7 +1106,7 @@ there is some English:
   This class template implements the Functor Design Pattern. It is used to declare the type of a **Callback**:
 
   * the first non-optional template argument represents the return type of the callback.
-  * the reminaining (optional) template arguments represent the type of the subsequent arguments to the callback.
+  * the remaining (optional) template arguments represent the type of the subsequent arguments to the callback.
   * up to nine arguments are supported.
 
 We are trying to figure out what the
@@ -1369,7 +1369,7 @@ didn't exist yet during configuration time?).  As a result, during the
 configuration phase you can't connect a trace source to a trace sink
 if one of them is created dynamically during the simulation.
 
-The two solutions to this connundrum are
+The two solutions to this conundrum are
 
 #. Create a simulator event that is run after the dynamic object is
    created and hook the trace when that event is executed; or
@@ -1456,7 +1456,7 @@ problem described above with ``Socket``.
   // ===========================================================================
   //
 
-This should also be self-explanatory.  
+This should also be self-explanatory.
 
 The next part is the declaration of the ``MyApp`` ``Application`` that
 we put together to allow the ``Socket`` to be created at configuration
@@ -2216,7 +2216,7 @@ creates a PCAP file named "sixth.pcap" with file mode "w".  This means
 that the new file is truncated (contents deleted) if an existing file
 with that name is found.  The final parameter is the "data link type"
 of the new PCAP file.  These are the same as the PCAP library data
-link types defined in ``bpf.h`` if you are familar with PCAP.  In this
+link types defined in ``bpf.h`` if you are familiar with PCAP.  In this
 case, ``DLT_PPP`` indicates that the PCAP file is going to contain
 packets prefixed with point to point headers.  This is true since the
 packets are coming from our point-to-point device driver.  Other