# HG changeset patch # User Tom Henderson # Date 1252110214 25200 # Node ID 04a9a7e9a624ddd83f2be0a52b7e3bccaadd1b55 # Parent 77c878bc3e846f28f28a8d21308a7a1b16ba7bb8 Manual spelling fixes from Johannes Buchner diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/attributes.texi --- a/doc/manual/attributes.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/attributes.texi Fri Sep 04 17:23:34 2009 -0700 @@ -297,7 +297,7 @@ Note that initialization of the attribute relies on the macro NS_OBJECT_ENSURE_REGISTERED (DropTailQueue) being called; if you leave this out of your new class implementation, your attributes will not be -initialized corretly. +initialized correctly. @subsection Basic usage @@ -521,7 +521,7 @@ uint32_t m_cWnd; // Congestion window @end verbatim -Suppose that someone working with Tcp wanted to get or set the +Suppose that someone working with TCP wanted to get or set the value of that variable using the metadata system. If it were not already provided by ns-3, the user could declare the following addition in the runtime metadata system (to the TypeId declaration for TcpSocket): @@ -597,7 +597,7 @@ of writing the conversions to/from strings and attribute values. Most of this can be copy/pasted with macro-ized code. For instance, consider class -delcaration for Rectangle in the @code{src/mobility/} directory: +declaration for Rectangle in the @code{src/mobility/} directory: @verbatim /** @@ -663,7 +663,7 @@ found in @code{src/contrib} and not in the main tree. If you like this feature and would like to provide feedback on it, please email us. -Values for ns-3 attributes can be stored in an ascii or XML text file and +Values for ns-3 attributes can be stored in an ASCII or XML text file and loaded into a future simulation. This feature is known as the ns-3 ConfigStore. The ConfigStore code is in @code{src/contrib/}. It is not yet main-tree diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/callbacks.texi --- a/doc/manual/callbacks.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/callbacks.texi Fri Sep 04 17:23:34 2009 -0700 @@ -19,7 +19,7 @@ Consider that you have two simulation models A and B, and you wish to have them pass information between them during the simulation. One way that you can do that is that you can make A and B each explicitly -knowledgable about the other, so that they can invoke methods on each +knowledgeable about the other, so that they can invoke methods on each other. @verbatim @@ -141,7 +141,7 @@ } @end verbatim -Consider also the following main program snippett: +Consider also the following main program snippet: @verbatim int main (int argc, char *argv[]) { diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/csma.texi --- a/doc/manual/csma.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/csma.texi Fri Sep 04 17:23:34 2009 -0700 @@ -139,7 +139,7 @@ net devices on the channel identically. You can think of a symmetrical hub in which the packet bits propagate to a central location and then back out equal length cables to the other devices on the channel. The single ``speed -of light'' delay then corresponds to the time it takes for: 1) a singal to +of light'' delay then corresponds to the time it takes for: 1) a signal to propagate from one CsmaNetDevice through its cable to the hub; plus 2) the time it takes for the hub to forward the packet out a port; plus 3) the time it takes for the signal in question to propagate to the destination net @@ -168,7 +168,7 @@ @item ReceiveEnable: Enable packet reception if true; @item EncapsulationMode: Type of link layer encapsulation to use; @item RxErrorModel: The receive error model; -@item TxQueue: The trasmit queue used by the device; +@item TxQueue: The transmit queue used by the device; @item InterframeGap: The optional time to wait between "frames"; @item Rx: A trace source for received packets; @item Drop: A trace source for dropped packets. @@ -181,7 +181,7 @@ Packets sent over the CsmaNetDevice are always routed through the transmit queue to provide a trace hook for packets sent out over the network. This transmit queue can be set (via attribute) to model different -queueing strategies. +queuing strategies. Also configurable by attribute is the encapsulation method used by the device. Every packet gets an EthernetHeader that includes the @@ -219,7 +219,7 @@ The CSMA net devices and channels are typically created and configured using the associated @code{CsmaHelper} object. The various ns3 device dhelpers -generatlly work in a simlar way, and their use is seen in many of our example +generally work in a similar way, and their use is seen in many of our example programs. The conceptual model of interest is that of a bare computer ``husk'' into which @@ -302,13 +302,13 @@ the random exponential backoff handler if a timeout is detected. Case (3) implies that a packet is dequeued from the transmit queue if it is -unable to be transmittted according to the backoff rules. It is important +unable to be transmitted according to the backoff rules. It is important to understand that this will appear as a Dequeued packet and it is easy to incorrectly assume that the packet was transmitted since it passed through the transmit queue. In fact, a packet is actually dropped by the net device in this case. The reason for this behavior is due to the definition of the -Queue Drop event. The m_traceDrop event is, by defintion, fired when a -packet cannot be enqueued on the transmit queue becasue it is full. This +Queue Drop event. The m_traceDrop event is, by definition, fired when a +packet cannot be enqueued on the transmit queue because it is full. This event only fires if the queue is full and we do not overload this event to indicate that the CsmaChannel is "full." diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/emu.texi --- a/doc/manual/emu.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/emu.texi Fri Sep 04 17:23:34 2009 -0700 @@ -78,9 +78,9 @@ @itemize @bullet @item Address: The Mac48Address of the device; @item DeviceName: The name of the underlying real device (e.g., ``eth1''); -@item Start: The simualtion time at which to enable the underlying socket; -@item Stop: The simualtion time at which to stop receiving from the underlying socket; -@item TxQueue: The trasmit queue used by the device; +@item Start: The simulation time at which to enable the underlying socket; +@item Stop: The simulation time at which to stop receiving from the underlying socket; +@item TxQueue: The transmit queue used by the device; @item InterframeGap: The optional time to wait between "frames"; @item Rx: A trace source for received packets; @end itemize @@ -88,7 +88,7 @@ Packets sent over the EmuNetDevice are always routed through the transmit queue to provide a trace hook for packets sent out over the network. This transmit queue can be set (via attribute) to model different -queueing strategies. +queuing strategies. @node Using the EmuNetDevice @section Using the EmuNetDevice @@ -102,8 +102,8 @@ is no channel, the global router will be unable to do this. The Emu net devices are typically created and configured using the associated -@code{EmuHelper} object. The various ns3 device helpers generatlly work in a -simlar way, and their use is seen in many of our example programs. +@code{EmuHelper} object. The various ns3 device helpers generally work in a +similar way, and their use is seen in many of our example programs. The conceptual model of interest is that of a bare computer ``husk'' into which you plug net devices. The bare computers are created using a @code{NodeContainer} @@ -173,8 +173,8 @@ transmit queue. Dequeues from the transmit queue happen immediately after the Enqueue event and just prior to the packet being sent to the underlying socket. This means that the transmit queue really only exists to fire on -enqueue and dequeue operations so the Emu device bhaves like other ns-3 -devices in this repect. +enqueue and dequeue operations so the Emu device behaves like other ns-3 +devices in this respect. @subsection Lower-Level (PHY) Hooks diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/emulation.texi --- a/doc/manual/emulation.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/emulation.texi Fri Sep 04 17:23:34 2009 -0700 @@ -35,7 +35,7 @@ We expect the primary use for this configuration will be to generate repeatable experimental results in a real-world network environment that includes all of -the ns-3 tracing, loging, visualization and statistics gathering tools. +the ns-3 tracing, logging, visualization and statistics gathering tools. In what can be viewed as essentially an inverse configuration, we allow ``real'' machines running native applications and protocol stacks to integrate with @@ -188,7 +188,7 @@ ed->SetAddress ("00:00:00:00:00:02"); @end verbatim -And then the IP address of the client or serveris set in the usual way using +And then the IP address of the client or server is set in the usual way using helpers. @verbatim diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/node.texi --- a/doc/manual/node.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/node.texi Fri Sep 04 17:23:34 2009 -0700 @@ -100,7 +100,7 @@ MakeCallback (&Ipv4L3Protocol::Receive, ipv4), Ipv4L3Protocol::PROT_NUMBER, 0); @end verbatim -and likewise for Ipv6, Arp, etc. +and likewise for Ipv6, ARP, etc. @section NodeList @@ -115,7 +115,7 @@ must be aggregated to it to provide useful node functionality. The ns-3 source code directory @code{src/internet-stack} provides -implmentation of TCP/IPv4-related components. These include IPv4, +implementation of TCP/IPv4-related components. These include IPv4, ARP, UDP, TCP, and other related protocols. Internet Nodes are not subclasses of class Node; they are simply Nodes @@ -289,7 +289,7 @@ To summarize, internally, the UDP implementation is organized as follows: @itemize @bullet -@item a @code{UdpImpl} class that implements the Udp socket factory +@item a @code{UdpImpl} class that implements the UDP socket factory functionality @item a @code{UdpL4Protocol} class that implements the protocol logic that is socket-independent diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/other.texi --- a/doc/manual/other.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/other.texi Fri Sep 04 17:23:34 2009 -0700 @@ -515,7 +515,7 @@ create this network, so we will just quickly go over the main sections of the script. -The first section creates a CSMA lan that will become the left side of the +The first section creates a CSMA LAN that will become the left side of the dumbbell network. This code should be very familiar since we used the same process to create our first example. @@ -549,7 +549,7 @@ CsmaIpv4Topology::AddIpv4Address (n3, nd3, "10.1.1.4", "255.255.255.0"); @end verbatim -The code to generate the CSMA lan on the right side is similar; only the names +The code to generate the CSMA LAN on the right side is similar; only the names have been changed. @verbatim @@ -582,9 +582,9 @@ CsmaIpv4Topology::AddIpv4Address (n7, nd7, "10.1.2.4", "255.255.255.0"); @end verbatim -Next, we create a point to point link to connect the two lans. We connect -the point-to-point channel between nodes three (on the left lan) and four -(on the right lan). You should recoginze this as substantially similar to +Next, we create a point to point link to connect the two LANs. We connect +the point-to-point channel between nodes three (on the left LAN) and four +(on the right LAN). You should recognize this as substantially similar to the link setup from the @code{point-to-point} example. @verbatim @@ -599,7 +599,7 @@ @end verbatim Then we configure data flows. We create four echo clients that send UDP -packets from the left side lan to servers created on the right side lan. +packets from the left side LAN to servers created on the right side LAN. Notice that we send 100 packets with an inter-packet gap of ten milliseconds instead of the single packet we have previously used. This data rate is sufficient to saturate the point-to-point link and will cause packets to be @@ -710,7 +710,7 @@ to some people, we'll take some time here and outline a simple methodology you can follow. -@section Object Design 101 --- Class Ipv4BusNetwork +@section Object Design 101 --- Class IPv4BusNetwork If you are a master of object oriented design, feel free to skip or skim this section, in which we derive a simplistic but fully operational bus network class. @@ -735,7 +735,7 @@ Immediately we can notice that at the highest level we are talking about the noun @emph{network}. This probably won't surprise you. We also have an adjective that modifies the noun --- @emph{bus}. This should lead us to our -first class defintion. Usually class names are constructed in the same way +first class definition. Usually class names are constructed in the same way as an English language sentence would be spoken. For example, one would speak of a @emph{bus network} in conversation, so we would normally create a @code{class BusNetwork} to represent it. @@ -1005,7 +1005,7 @@ @section Using Ipv4BusNetwork If all you ever want to do with a bus network can be captured in a topology -with four nodes on the bus, the preceeding section may seem like a colossal +with four nodes on the bus, the preceding section may seem like a colossal waste of time. This is probably not the case, though. Now that we have a relatively abstract bus class, we can create bus networks with 4, 40 or 4000 nodes with no additional effort. @@ -1044,7 +1044,7 @@ This concludes the first part of the tutorial. We have focused on using the @command{ns-3} system to construct various network topologies and to -simulate sendng data across the networks; and we've shown you how to use the +simulate sending data across the networks; and we've shown you how to use the trace facility to get access to simulation results. We now encourage you to play with the system a little. Experiment with what @@ -1058,7 +1058,7 @@ examining the lower levels of the system in more detail. We are going to explain how to change the behavior of the system and eventually how to write new models and applications. This is a good time to make sure that you -thorougly understand what we've gone over so far. +thoroughly understand what we've gone over so far. @c ======================================================================== @c Object Model @@ -1365,7 +1365,7 @@ Technically, the class named @code{Object} is simply a base class that you will inherit from if you want your @code{Objects} to support aggregation and discovery. Many systems have a base class that implements common -functionality and these base classes are typically called somthing like +functionality and these base classes are typically called something like Object. The @command{ns-3} version of this base class relates primarily to @code{Object} aggregation and discovery, although it does also provide methods to help with intrusive reference counting and tracing as well. @@ -1383,7 +1383,7 @@ For those of you unfamiliar with Microsoft COM, CORBA or ORBit, this might sound obvious. For those of with such a background, the point we are making is that there is no such thing in @command{ns-3} as a separate Interface -declaration, no such thing as an Interface Definiition Language, no such thing +declaration, no such thing as an Interface Definition Language, no such thing as a UUID or GUID, etc. In @command{ns-3} we just work with C++ objects that may be given some very useful abilities by inheriting from the @command{ns-3} base class @code{Object}. @command{Ns-3} @code{Objects} are not required to @@ -1422,7 +1422,7 @@ @code{Object}. So, when the @code{Node} object is created it is really an aggregation of one @code{Object} and you can call @code{AggregateObject} or @code{GetObject} on the resulting @code{Node} object. Along with being an -aggregation, the @code{Node} class also describes a public interface. THis +aggregation, the @code{Node} class also describes a public interface. This public interface (API) is declared just as any C++ object is declared, via its class methods as specified in the inheritance tree. For those steeped in COM or CORBA, this is where the concept of Interface works in @command{ns-3}. @@ -1435,7 +1435,7 @@ The line with the circle at the top of the diagram represents the appearance of the @code{Object} API to the external world. This circle and line are together called a lollipop because of its superficial similarity to a kind of -childs candy. +child's candy. @sp 1 @center @image{oneobj,,,,png} @@ -1514,7 +1514,7 @@ a->AggregateObject (c); @end verbatim -Thats all there is to it. Now that you have those connectors snapped +That's all there is to it. Now that you have those connectors snapped together, you can ask each of the @code{Objects} in the aggregation for any of the other @code{Objects} in the aggregation. Lets look at a simple example: @@ -1527,11 +1527,11 @@ @code{B} to help with memory management of the returned @code{Object} pointer. You should be very familiar with smart pointers at this stage of the tutorial. -The right hand side illustrates how @code{GetObject} is acutally used. -The method @code{GetObject} is templated. The assocated template parameter +The right hand side illustrates how @code{GetObject} is actually used. +The method @code{GetObject} is templated. The associated template parameter (between the brackets) specifies the @emph{class} that is being requested. This is important. Since it is the class type that specifies the search -criteron, there can be only one instance of a particular class present in an +criterion, there can be only one instance of a particular class present in an aggregation. Looking back a little, although the parameter to @code{AggregateObject} appears to be a vanilla C++ object (@code{b} or @code{c} above), it actually represents (is an instance of) a class that has an @@ -1648,7 +1648,7 @@ @cindex TypeId @cindex GetTypeId The final piece of this puzzle is the @code{TypeId}. Recall that the -declaration our eample object above included the following code +declaration our example object above included the following code @verbatim static ns3::TypeId GetTypeId (void) @@ -1724,7 +1724,7 @@ @code{class A}, and is initialized by a call to the constructor for the class @code{TypeId}. The constructor for @code{TypeId} takes a @code{std::string} that can be used to locate the type information for your class. We usually -privide the class name as the string. +provide the class name as the string. Hopefully, this much of the declaration is now clear: @@ -1787,7 +1787,7 @@ AddConstructor (); @end verbatim -You can interpret this as explaining to the @command{ns-3} object ssytem that +You can interpret this as explaining to the @command{ns-3} object system that you have a constructor named @code{A::A} which takes no parameters. You are saying that this constructor should be used when @code{CreateObject} is called with no parameters. @@ -2077,10 +2077,10 @@ @emph{Remember: Object types do not identify objects.} -@subsection Dont use GetObject to Check Your Own Type. +@subsection Don't use GetObject to Check Your Own Type. @cindex GetObject It is tempting to use @code{GetObject} as a form of runtime type -information. Dont do it. You have no control over what @emph{other} +information. Don't do it. You have no control over what @emph{other} object may be added to your aggregation. Someone else may have appropriated (reimplemented) your type and aggregated themselves onto the aggregation. diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/output.texi --- a/doc/manual/output.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/output.texi Fri Sep 04 17:23:34 2009 -0700 @@ -72,7 +72,7 @@ the @command{ns-3} low-level tracing system that lets you get access to underlying trace events easily. The output of a trace of a simulation run is an ASCII file --- thus the name. -In the spririt of keeping things simple, you won't be able to control or +In the spirit of keeping things simple, you won't be able to control or configure the output at this stage. For those familiar with @command{ns-2} output, this type of trace is @@ -121,10 +121,10 @@ change into the top level directory and take a look at the file @code{tutorial.tr} in your favorite editor. -@subsubsection Parsing Ascii Traces -@cindex parsing ascii traces +@subsubsection Parsing ASCII Traces +@cindex parsing ASCII traces -This section parses in detail the structure of the ascii tracing +This section parses in detail the structure of the ASCII tracing output. If you find this output format self explanatory (it resembles tcpdump output), you may skip to the next section on pcap tracing. @@ -191,7 +191,7 @@ zero. Therefore, @code{nodeid=0} means that the node in which the given trace event originated is the first node we created. In the case of our script, this first node is is the node pointed to by the smart pointer @code{n0}. Not -too surpsisingly, this is also the node to which we attached the +too surprisingly, this is also the node to which we attached the @code{UdpEchoClient}. The device number is local to each node, and so the device given by @code{device=0} is the first net device that we added to the node in question. In our simulation, this corresponds to the @@ -269,10 +269,10 @@ Looking at the packet payload (references 10-14) we see that this is an ARP reply to the request sent by node one. Note that the simulation time (reference 01) is now 2.00207 seconds. This is direct result of the data rate -(5 mb/s) and latency (2 ms) parameters that we passed to the +(5 MB/s) and latency (2 ms) parameters that we passed to the @code{CsmaChannel} when we created it. Clearly the ARP request packet was sent over the channel and received approximately 2 ms later by node one. A -corresponding ARP response packet was created and enqueued on node one's net +corresponding ARP response packet was created and enqueued on node ones net device. It is this enqueue trace event that has being logged. @cindex queue @@ -339,7 +339,7 @@ on that node has turned the packet around. Just as node zero needed to ARP for the MAC address of node one, now node one must ARP for the MAC address of node zero. We see the ARP request enqueued on the transmit queue of node one; -then we see the ARP request dequeued from the tranmit queue of node one (and +then we see the ARP request dequeued from the transmit queue of node one (and implicitly transmitted to node zero). Then we see an ARP response enqueued on the transmit queue of node zero; and finally the ARP response dequeued (and implicitly transmitted back to node one). @@ -396,7 +396,7 @@ The code used to enable pcap tracing is similar to that for ASCII tracing. We have provided another file, @code{tutorial-csma-echo-pcap-trace.cc} that uses the pcap trace wrapper. We have added the code to include the pcap -trace wrapper defintions: +trace wrapper definitions: @verbatim #include "ns3/pcap-trace.h" @@ -447,7 +447,7 @@ @subsubsection Reading output with Wireshark @cindex Wireshark -If you are unfamilar with Wireshark, there is a web site available from which +If you are unfamiliar with Wireshark, there is a web site available from which you can download programs and documentation: @uref{http://www.wireshark.org/}. If you have Wireshark available, you can open each of the trace files and diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/packets.texi --- a/doc/manual/packets.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/packets.texi Fri Sep 04 17:23:34 2009 -0700 @@ -59,7 +59,7 @@ layer. Memory management of Packet objects is entirely automatic and extremely -efficient: memory for the application-level payload can be modelized by +efficient: memory for the application-level payload can be modeled by a virtual buffer of zero-filled bytes for which memory is never allocated unless explicitly requested by the user or unless the packet is fragmented or serialized out to a real network device. @@ -458,7 +458,7 @@ @verbatim Ptr p; // pointer to a pre-existing packet SocketIpTtlTag tag - tag.SetTtl (m_ipMulticastTtl); // Convey the TTL from Udp layer to IP layer + tag.SetTtl (m_ipMulticastTtl); // Convey the TTL from UDP layer to IP layer p->AddPacketTag (tag); @end verbatim @@ -636,7 +636,7 @@ On the other hand, copying a Packet and its tags is a matter of copying the TagData head pointer and incrementing its reference count. -Tags are found by the unique mapping betweent the Tag type and +Tags are found by the unique mapping between the Tag type and its underlying id. This is why at most one instance of any Tag can be stored in a packet. The mapping between Tag type and underlying id is performed by a registration as follows: diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/point-to-point.texi --- a/doc/manual/point-to-point.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/point-to-point.texi Fri Sep 04 17:23:34 2009 -0700 @@ -35,7 +35,7 @@ @itemize @bullet @item Address: The ns3::Mac48Address of the device (if desired); @item DataRate: The data rate (ns3::DataRate) of the device; -@item TxQueue: The trasmit queue (ns3::Queue) used by the device; +@item TxQueue: The transmit queue (ns3::Queue) used by the device; @item InterframeGap: The optional ns3::Time to wait between "frames"; @item Rx: A trace source for received packets; @item Drop: A trace source for dropped packets. @@ -78,7 +78,7 @@ The PointToPoint net devices and channels are typically created and configured using the associated @code{PointToPointHelper} object. The various ns3 device helpers -generally work in a simlar way, and their use is seen in many of our example +generally work in a similar way, and their use is seen in many of our example programs and is also covered in the ns-3 tutorial. The conceptual model of interest is that of a bare computer ``husk'' into which @@ -93,7 +93,7 @@ Once you have your nodes, you need to instantiate a @code{PointToPointHelper} and set any attributes you may want to change. Note that since this is a point-to-point -(as compared to a point-to-mulipoint) there may only be two nodes with associated +(as compared to a point-to-multipoint) there may only be two nodes with associated net devices connected by a PointToPointChannel. @verbatim diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/random.texi --- a/doc/manual/random.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/random.texi Fri Sep 04 17:23:34 2009 -0700 @@ -28,7 +28,7 @@ @itemize @bullet @item @strong{by default, ns-3 simulations use a fixed seed}; if there is any randomness in the simulation, each run of the program will yield identical -results uniess the seed and/or run number is changed. +results unless the seed and/or run number is changed. @itemize @bullet @item @strong{in ns-3.3 and earlier, ns-3 simulations used a random seed by default; this marks a change in policy starting with ns-3.4} @@ -81,7 +81,7 @@ the first stream might use the first N/2 values and the second stream might produce the second N/2 values. An important property here is that the two streams are uncorrelated. Likewise, each -stream can be partitioned disjointly to a number of +stream can be partitioned disjointedly to a number of uncorrelated @emph{substreams}. The underlying RNG hopefully produces a pseudo-random sequence of numbers with a very long cycle length, and partitions this into streams and substreams in an diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/routing.texi --- a/doc/manual/routing.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/routing.texi Fri Sep 04 17:23:34 2009 -0700 @@ -225,7 +225,7 @@ by the simulation author) until a route is found. We chose this approach because it may better -faciliate the integration of disparate routing approaches that may +facilitate the integration of disparate routing approaches that may be difficult to coordinate the writing to a single table, approaches where more information than destination IP address (e.g., source routing) is used to determine the next hop, and on-demand @@ -300,7 +300,7 @@ Typically there are two main types of multicast routes: routes of the first kind are used during forwarding. All of the conditions must be -exlicitly provided. The second kind of routes are used to get packets off +explicitly provided. The second kind of routes are used to get packets off of a local node. The difference is in the input interface. Routes for forwarding will always have an explicit input interface specified. Routes off of a node will always set the input interface to a wildcard specified diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/sockets.texi --- a/doc/manual/sockets.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/sockets.texi Fri Sep 04 17:23:34 2009 -0700 @@ -177,7 +177,7 @@ Similarly, passing in a zero to the pointer argument in the raw buffer variants has the same effect. Note that, if some subsequent code tries to read the Packet data buffer, the fake buffer will be converted to -a real (zero'ed) buffer on the spot, and the efficiency will be lost there. +a real (zeroed) buffer on the spot, and the efficiency will be lost there. @subsection Socket options diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/tcp.texi --- a/doc/manual/tcp.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/tcp.texi Fri Sep 04 17:23:34 2009 -0700 @@ -28,7 +28,7 @@ ... } @end verbatim -The parameter @code{m_tid} controls the TypeId of the actual Tcp Socket +The parameter @code{m_tid} controls the TypeId of the actual TCP Socket implementation that is instantiated. This way, the application can be written generically and different socket implementations can be swapped out by specifying the TypeId. @@ -138,7 +138,7 @@ @subsection Configuring and Downloading -NSC is disbled by default and must be explicitly configured in. To try +NSC is disabled by default and must be explicitly configured in. To try this, type @verbatim ./waf configure --enable-nsc @@ -210,7 +210,7 @@ The key line is the @code{SetNscStack}. This tells the InternetStack helper to aggregate instances of NSC TCP instead of native ns-3 TCP to the remaining nodes. It is important that this function be called -@strong{before} callling the @code{Install()} function, as shown above. +@strong{before} calling the @code{Install()} function, as shown above. Which stacks are available to use? Presently, the focus has been on Linux 2.6.18 and Linux 2.6.26 stacks for ns-3. To see which stacks diff -r 77c878bc3e84 -r 04a9a7e9a624 doc/manual/wifi.texi --- a/doc/manual/wifi.texi Fri Sep 04 17:27:33 2009 +0200 +++ b/doc/manual/wifi.texi Fri Sep 04 17:23:34 2009 -0700 @@ -128,11 +128,11 @@ configuration of the WifiNetDevice powerful but complex. For this reason, we provide some helper classes to perform common operations in a simple matter, and leverage the ns-3 attribute system to allow users to control -the parameterization of the underlying models. +the parametrization of the underlying models. Users who use the low-level ns-3 API and who wish to add a WifiNetDevice to their node must create an instance of a WifiNetDevice, plus -a number of consitutent objects, and bind them together appropriately +a number of constituent objects, and bind them together appropriately (the WifiNetDevice is very modular in this regard, for future extensibility). At the low-level API, this can be done with about 20 lines of code (see @code{ns3::WifiHelper::Install}, and