diff --git a/doc/manual/node.texi b/doc/manual/node.texi index 31d8b8561..61fbf727f 100644 --- a/doc/manual/node.texi +++ b/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: diff --git a/doc/tutorial/building-topologies.texi b/doc/tutorial/building-topologies.texi index e61e802b0..3819b124f 100644 --- a/doc/tutorial/building-topologies.texi +++ b/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 diff --git a/doc/tutorial/conceptual-overview.texi b/doc/tutorial/conceptual-overview.texi index 4c0664be2..040ade27c 100644 --- a/doc/tutorial/conceptual-overview.texi +++ b/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 diff --git a/doc/tutorial/in-process/introduction.texi b/doc/tutorial/in-process/introduction.texi index 248120e3f..f57fa0236 100644 --- a/doc/tutorial/in-process/introduction.texi +++ b/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 diff --git a/doc/tutorial/tweaking.texi b/doc/tutorial/tweaking.texi index caeac8666..05edf3e89 100644 --- a/doc/tutorial/tweaking.texi +++ b/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: