Fix misprints in tutorial (bug 453)

doc/manual/node.texi

@@ -204,7 +204,7 @@ focus on the above four items from an architectural perspective.
 
 First, note that the @code{Receive ()} function has a matching signature
 to the ReceiveCallback in the @code{class Node}.  This function pointer
-is inserted into the the Node's protocol handler when 
+is inserted into the Node's protocol handler when 
 @code{AddInterface ()} is called.  The actual registration is done
 with a statement such as:
 follows:

doc/tutorial/building-topologies.texi

@@ -133,7 +133,7 @@ done in @code{first.cc}.
   p2pNodes.Create (2);
 @end verbatim
 
-Next, we delare another @code{NodeContainer} to hold the nodes that will be
+Next, we declare another @code{NodeContainer} to hold the nodes that will be
 part of the bus (CSMA) network.  First, we just instantiate the container
 object itself.  
 
@@ -171,7 +171,7 @@ We mentioned above that you were going to see a helper for CSMA devices and
 channels, and the next lines introduce them.  The @code{CsmaHelper} works just
 like a @code{PointToPointHelper}, but it creates and connects CSMA devices and
 channels.  In the case of a CSMA device and channel pair, notice that the data
-rate is specified by a @em{channel} attribute instead of a device attribute.
+rate is specified by a @emph{channel} attribute instead of a device attribute.
 This is because a real CSMA network does not allow one to mix, for example, 
 10Base-T and 100Base-T devices on a given channel.  We first set the data rate
 to 100 megabits per second, and then set the speed-of-light delay of the channel
@@ -260,9 +260,9 @@ the constructor.
 Recall that the @code{csmaNodes NodeContainer} contains one of the 
 nodes created for the point-to-point network and @code{nCsma} ``extra'' nodes. 
 What we want to get at is the last of the ``extra'' nodes.  The zeroth entry of
-the @code{csmaNodes} container will the the point-to-point node.  The easy
+the @code{csmaNodes} container will be the point-to-point node.  The easy
 way to think of this, then, is if we create one ``extra'' CSMA node, then it
-will be be at index one of the @code{csmaNodes} container.  By induction,
+will be at index one of the @code{csmaNodes} container.  By induction,
 if we create @code{nCsma} ``extra'' nodes the last one will be at index 
 @code{nCsma}.  You see this exhibited in the @code{Get} of the first line of 
 code.
@@ -367,7 +367,7 @@ only trace from that node.
 
 Now look at @code{second-1-0.pcap} and @code{second-1-1.pcap}.  The former is
 the pcap trace for device zero on node one and the latter is the trace file 
-for device one on node one.  If you refer back to the topology illustrration at
+for device one on node one.  If you refer back to the topology illustration at
 the start of the section, you will see that node one is the node that has
 both a point-to-point device and a CSMA device, so we should expect two pcap
 traces for that node.
@@ -416,7 +416,7 @@ ultimate destination.  Let's then look at second-1-1.pcap and see if its there.
   ~/repos/ns-3-dev >
 @end verbatim
 
-As you can see, the link type is now ``Ethernet.''  Something new has appeared,
+As you can see, the link type is now ``Ethernet''.  Something new has appeared,
 though.  The bus network needs @code{ARP}, the Address Resolution Protocol.
 The node knows it needs to send the packet to IP address 10.1.2.4, but it
 doesn't know the MAC address of the corresponding node.  It broadcasts on the
@@ -445,7 +445,7 @@ echo server,
   ~/repos/ns-3-dev >
 @end verbatim
 
-Again, you see that the link type is ``Ethernet.''  The first two entries are
+Again, you see that the link type is ``Ethernet''.  The first two entries are
 the ARP exchange we just explained.  The third packet is the echo packet 
 being delivered to its final destination.
 
@@ -706,7 +706,7 @@ on the nodes and the channel between them.
   p2pDevices = pointToPoint.Install (p2pNodes);
 @end verbatim
 
-Next, we delare another @code{NodeContainer} to hold the nodes that will be
+Next, we declare another @code{NodeContainer} to hold the nodes that will be
 part of the bus (CSMA) network.
 
 @verbatim
@@ -835,7 +835,7 @@ attributes (and channel) as the stations:
 Now, we are going to add mobility models.  We want the STA nodes to be mobile,
 wandering around inside a bounding box, and we want to make the AP node 
 stationary.  We use the @code{MobilityHelper} to make this easy for us.
-First, we instantiate a @code{MobilityHelper} obejct and set some attributes
+First, we instantiate a @code{MobilityHelper} object and set some attributes
 controlling the ``position allocator'' functionality.
 
 @verbatim
@@ -854,7 +854,7 @@ This code tells the mobility helper to use a two-dimensional grid to initially
 place the STA nodes.  Feel free to explore the Doxygen for class 
 @code{ns3::GridPositionAllocator} to see exactly what is being done.
 
-We have aranged our nodes on an initial grid, but now we need to tell them
+We have arranged our nodes on an initial grid, but now we need to tell them
 how to move.  We choose the @code{RandomWalk2dMobilityModel} which has the 
 nodes move in a random direction at a random speed around inside a bounding 
 box.
@@ -896,7 +896,7 @@ Just as in the @code{second.cc} example script, we are going to use the
 @code{Ipv4AddressHelper} to assign IP addresses to our device interfaces.
 First we use the network 10.1.1.0 to create the two addresses needed for our
 two point-to-point devices.  Then we use network 10.1.2.0 to assign addresses
-the the CSMA network and then we assign addresses from network 10.1.3.0 to
+to the CSMA network and then we assign addresses from network 10.1.3.0 to
 both the STA devices and the AP on the wireless network.
 
 @verbatim
@@ -941,7 +941,7 @@ the server on the CSMA network.  We have also seen similar operations before.
   clientApps.Stop (Seconds (10.0));
 @end verbatim
 
-Since we have built an internetwork here, we need enable internetwork routing
+Since we have built an internetwork here, we need to enable internetwork routing
 just as we did in the @code{second.cc} example script.
 
 @verbatim

doc/tutorial/conceptual-overview.texi

@@ -82,7 +82,7 @@ network packets
 @cindex Channel
 
 In the real world, one can connect a computer to a network.  Often the media
-over which data flows in these netowrks are called @emph{channels}.  When
+over which data flows in these networks are called @emph{channels}.  When
 you connect your Ethernet cable to the plug in the wall, you are connecting 
 your computer to an Ethernet communication channel.  In the simulated world
 of @command{ns-3}, one connects a @code{Node} to an object representing a
@@ -505,7 +505,7 @@ the two @code{PointToPointNetDevices} are attached.  When objects are created
 by the @code{PointToPointHelper}, the attributes previously set in the helper
 are used to initialize the corresponding attributes in the created objects.
 
-After executing the the @code{pointToPoint.Install (nodes)} call we will have
+After executing the @code{pointToPoint.Install (nodes)} call we will have
 two nodes, each with an installed point-to-point net device and a 
 point-to-point channel between them.  Both devices will be configured to 
 transmit data at five megabits per second over the channel which has a two 
@@ -658,9 +658,9 @@ helper constructors.
 
 Recall that we used an @code{Ipv4InterfaceContainer} to keep track of the IP 
 addresses we assigned to our devices.  The zeroth interface in the 
-@code{interfaces} container is going to coorespond to the IP address of the 
+@code{interfaces} container is going to correspond to the IP address of the 
 zeroth node in the @code{nodes} container.  The first interface in the 
-@code{interfaces} container cooresponds to the IP address of the first node 
+@code{interfaces} container corresponds to the IP address of the first node 
 in the @code{nodes} container.  So, in the first line of code (from above), we
 are creating the helper and telling it so set the remote address of the client
 to be  the IP address assigned to the node on which the server resides.  We 
@@ -756,7 +756,7 @@ and then build it using waf,
 @end verbatim
 
 You can now run the example (note that if you build your program in the scratch
-directory you must run it out of the scratch direcory):
+directory you must run it out of the scratch directory):
 
 @verbatim
   ~/repos/ns-3-dev > ./waf --run scratch/first

doc/tutorial/in-process/introduction.texi

@@ -676,7 +676,7 @@ used to generate and echo simulated network packets
 @cindex Channel
 
 In the real world, one can connect a computer to a network.  Often the media
-over which data flows in these netowrks are called @emph{channels}.  When
+over which data flows in these networks are called @emph{channels}.  When
 you connect your Ethernet cable to the plug in the wall, you are connecting 
 your computer to an Ethernet communication channel.  In the simulated world
 of ns-3 one connects a @code{Node} to an object representing a

doc/tutorial/tweaking.texi

@@ -744,7 +744,7 @@ out interesting parts of the received packet.
 
 The rationale for this explicit division is to allow users to attach new
 types of sinks to existing tracing sources, without requiring editing and 
-recompilation of the the core of the simulator.  Thus, in the example above, 
+recompilation of the core of the simulator.  Thus, in the example above, 
 a user could define a new tracing sink in her script and attach it to an 
 existing tracing source defined in the simulation core by editing only the 
 user script.
@@ -885,7 +885,7 @@ operation happened on the transmit queue of the device.  This is reflected in
 the final segments of the ``trace path'' which are @code{TxQueue/Enqueue}.
 
 The remaining lines in the trace should be fairly intuitive.  References 03-04
-indicate that the packet is encapulated in the point-to-point protocol.  
+indicate that the packet is encapsulated in the point-to-point protocol.  
 References 05-07 show that the packet has an IP version four header and has
 originated from IP address 10.1.1.1 and is destined for 10.1.1.2.  References
 08-09 show that this packet has a UDP header and, finally, reference 10 shows
@@ -952,7 +952,7 @@ file names will be built using the prefix, the node number, the device number
 
 In our example script, we will eventually see files named ``first-0-0.pcap'' 
 and ``first.1-0.pcap'' which are the pcap traces for node 0-device 0 and 
-node 1-device 1, respectively.
+node 1-device 0, respectively.
 
 Once you have added the line of code to enable pcap tracing, you can run the
 script in the usual way: