--- a/doc/manual/node.texi Thu Dec 18 22:33:33 2008 -0800
+++ b/doc/manual/node.texi Sat Dec 27 13:58:12 2008 -0800
@@ -204,7 +204,7 @@
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:
--- a/doc/tutorial/building-topologies.texi Thu Dec 18 22:33:33 2008 -0800
+++ b/doc/tutorial/building-topologies.texi Sat Dec 27 13:58:12 2008 -0800
@@ -133,7 +133,7 @@
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 @@
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 @@
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 @@
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 @@
~/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 @@
~/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 @@
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 @@
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 @@
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 @@
@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 @@
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
--- a/doc/tutorial/conceptual-overview.texi Thu Dec 18 22:33:33 2008 -0800
+++ b/doc/tutorial/conceptual-overview.texi Sat Dec 27 13:58:12 2008 -0800
@@ -82,7 +82,7 @@
@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 @@
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 @@
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 @@
@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
--- a/doc/tutorial/in-process/introduction.texi Thu Dec 18 22:33:33 2008 -0800
+++ b/doc/tutorial/in-process/introduction.texi Sat Dec 27 13:58:12 2008 -0800
@@ -676,7 +676,7 @@
@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
--- a/doc/tutorial/tweaking.texi Thu Dec 18 22:33:33 2008 -0800
+++ b/doc/tutorial/tweaking.texi Sat Dec 27 13:58:12 2008 -0800
@@ -744,7 +744,7 @@
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 @@
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 @@
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: