ns-3.24: comparison doc/tutorial/tracing.texi

equal deleted inserted replaced

-:e1728a633e69
+:450a3f4d9906
 strategies to work with in @code{ns-3}: using generic pre-defined bulk output
 mechanisms and parsing their content to extract interesting information; or
 somehow developing an output mechanism that conveys exactly (and perhaps only)
 the information wanted.
-Using pre-defined bulk output mechansims has the advantage of not requiring any
+Using pre-defined bulk output mechanisms has the advantage of not requiring any
 changes to @code{ns-3}, but it does require programming.  Often, pcap or NS_LOG
 output messages are gathered during simulation runs and separately run through
 scripts that use grep, sed or awk to parse the messages and reduce and transform
 the data to a manageable form.  Programs must be written to do the
 transformation, so this does not come for free.  Of course, if the information
 The difference is due to the fact that two @code{GetObject} calls are implied
 in the string found in the documentation.  The first, for @code{$ns3::MobilityModel}
 will query the aggregation for the base class.  The second implied
 @code{GetObject} call, for @code{$ns3::RandomWalk2dMobilityModel}, is used to ``cast''
-the base class to the concrete imlementation class.  The documentation shows
+the base class to the concrete implementation class.  The documentation shows
 both of these operations for you.  It turns out that the actual Attribute you are
 going to be looking for is found in the base class as we have seen.
 Look further down in the @code{GetTypeId} doxygen.  You will find,
 app->SetStopTime (stopTime);
 @end verbatim
 as a result of the @code{apps.Stop} call.
-The ulitmate result of these calls is that we want to have the simulator
+The ultimate result of these calls is that we want to have the simulator
 automatically make calls into our @code{Applications} to tell them when to
 start and stop.  In the case of @code{MyApp}, it inherits from class
 @code{Application} and overrides @code{StartApplication}, and
 @code{StopApplication}.  These are the functions that will be called by
 the simulator at the appropriate time.  In the case of @code{MyApp} you
 Take a look at @code{src/core/object.cc} next and search for @code{Object::Start}.
 This code is not as straightforward as you might have expected since
 @command{ns-3} @code{Objects} support aggregation.  The code in
 @code{Object::Start} then loops through all of the objects that have been
-aggretated together and calls their @code{DoStart} method.  This is another
+aggregated together and calls their @code{DoStart} method.  This is another
 idiom that is very common in @command{ns-3}.  There is a public API method,
 that stays constant across implementations, that calls a private implementation
 method that is inherited and implemented by subclasses.  The names are typically
 something like @code{MethodName} for the public API and @code{DoMethodName} for
 the private API.
 m_sendEvent = Simulator::Schedule (tNext, &MyApp::SendPacket, this);
 }
 }
 @end verbatim
-Here, you see that @code{ScheduleTx} does exactly that.  If the @code{Applciation}
+Here, you see that @code{ScheduleTx} does exactly that.  If the @code{Application}
 is running (if @code{StopApplication} has not been called) it will schedule a
 new event, which calls @code{SendPacket} again.  The alert reader will spot
 something that also trips up new users.  The data rate of an @code{Application} is
 just that.  It has nothing to do with the data rate of an underlying @code{Channel}.
 This is the rate at which the @code{Application} produces bits.  It does not take
 Device helpers and protocol helpers.  Device helpers look at the problem
 of specifying which traces should be enabled through a node, device pair.  For
 example, you may want to specify that pcap tracing should be enabled on a
 particular device on a specific node.  This follows from the @code{ns-3} device
 conceptual model, and also the conceptual models of the various device helpers.
-Following naturallyu from this, the files created follow a
+Following naturally from this, the files created follow a
 <prefix>-<node>-<device> naming convention.
 Protocol helpers look at the problem of specifying which traces should be
 enabled through a protocol and interface pair.  This follows from the @code{ns-3}
 protocol stack conceptual model, and also the conceptual models of internet
 Finally, two of the methods shown above,
 @verbatim
 void EnablePcap (std::string prefix, Ptr<NetDevice> nd, bool promiscuous = false, bool explicitFilename = false);
-void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilenaqme = false);
+void EnablePcap (std::string prefix, std::string ndName, bool promiscuous = false, bool explicitFilename = false);
 @end verbatim
 have a default parameter called @code{explicitFilename}.  When set to true,
 this parameter disables the automatic filename completion mechanism and allows
 you to create an explicit filename.  This option is only available in the
 taken for devices in the @code{ns-3} system are of the form
 ``<prefix>-<node id>-<device id>.pcap''.  In the case of protocol traces,
 there is a one-to-one correspondence between protocols and @code{Nodes}.
 This is because protocol @code{Objects} are aggregated to @code{Node Objects}.
 Since there is no global protocol id in the system, we use the corresponding
-node id in file naming.  Threfore there is a possibility for file name
+node id in file naming.  Therefore there is a possibility for file name
 collisions in automatically chosen trace file names.  For this reason, the
 file name convention is changed for protocol traces.
 As previously mentioned, every node in the system will have a system-assigned
 node id.  Since there is a one-to-one correspondence between protocol instances
 in the @code{ns-3} system are of the form ``<prefix>-<node id>-<device id>.tr''
 As previously mentioned, every node in the system will have a system-assigned
 node id.  Since there is a one-to-one correspondence between protocols and nodes
 we use to node-id to identify the protocol identity.  Every interface on a
-given rotocol will have an interface index (also called simply an interface)
+given protocol will have an interface index (also called simply an interface)
 relative to its protocol.  By default, then, an ascii trace file created as a result
 of enabling tracing on the first device of node 21, using the prefix ``prefix'',
 would be ``prefix-n21-i1.tr''.  Use the prefix to disambiguate multiple protocols
 per node.
 There are high-level helper functions that allow users to simply control the
 collection of pre-defined outputs to a fine granularity.  There are mid-level
 helper functions to allow more sophisticated users to customize how information
 is extracted and saved; and there are low-level core functions to allow expert
 users to alter the system to present new and previously unexported information
-in a way that will be immediatly accessible to users at higher levels.
+in a way that will be immediately accessible to users at higher levels.
 This is a very comprehensive system, and we realize that it is a lot to
 digest, especially for new users or those not intimately familiar with C++
 and its idioms.  We do consider the tracing system a very important part of
 @code{ns-3} and so recommend becoming as familiar as possible with it.  It is

changeset 6189	450a3f4d9906
parent 6105	aa0d0770a4b2
child 6225	ada86e5d646c