diff --git a/doc/tutorial/source/building-topologies.rst b/doc/tutorial/source/building-topologies.rst index 450061d62..24bc59f0e 100644 --- a/doc/tutorial/source/building-topologies.rst +++ b/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. diff --git a/doc/tutorial/source/conceptual-overview.rst b/doc/tutorial/source/conceptual-overview.rst index 3bb620c59..0d49102bd 100644 --- a/doc/tutorial/source/conceptual-overview.rst +++ b/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 diff --git a/doc/tutorial/source/getting-started.rst b/doc/tutorial/source/getting-started.rst index 2303b22bc..7eb2170eb 100644 --- a/doc/tutorial/source/getting-started.rst +++ b/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 diff --git a/doc/tutorial/source/tracing.rst b/doc/tutorial/source/tracing.rst index e3e5c7366..86db147b7 100644 --- a/doc/tutorial/source/tracing.rst +++ b/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