dynamics.tex

柯老师网站上找到的

\fcnref{\proc[]{down}}{../ns-2/dynamics.tcl}{rtModel/Trace::down}
to use \proc[]{set-trace-events}.

\paragraph{Manual}
The model is designed to fire exactly once.
The instance procedure
\fcnref{\proc[]{set-parms}}{../ns-2/dynamics.tcl}{rtModel/Manual::set-parms}
takes an operation and the time to execute that operation as arguments.
\fcnref{\proc[]{set-first-event}}{../ns-2/dynamics.tcl}{rtModel/Manual::set-first-event}
will schedule the event at the appropriate moment.

This routine also redefines
\fcnref{\proc[]{notify}}{../ns-2/dynamics.tcl}{rtModel/Manual::notify}
to delete the object instance when the operation is completed.
This notion of the object deleting itself is fragile code.

Since the object only fires once and does nto have to be rescheduled,
it does not overload the procedures \proc[]{up} or \proc[]{down}.

\subsection{\protect\clsref{rtQueue}{../ns-2/dynamics.tcl}}
\label{sec:rtqueue}

The simulator needs to co-ordinate multiple simultaneous network
dynamics events, especially to ensure the right coherent behaviour.
Hence, the network dynamics models use their own internal 
route queue to schedule dynamics events.
There is one instance of this object in the simulator, in the
class Simulator instance variable \code{rtq_}.

The queue object stores an array of queued operations
in its instance variable, \code{rtq_}.
The index is the time at which the event will execute.
Each element is the list of operations that will execute at that time.

The instance procedures
\fcnref{\proc[]{insq}}{../ns-2/dynamics.tcl}{rtQueue::insq} and
\fcnref{\proc[]{insq-i}}{../ns-2/dynamics.tcl}{rtQueue::insq-i}
can insert an element into the queue.
\begin{list}{}{}
\item The first argument is the time at which this operation will execute.
  \proc[]{insq} takes the exact time as argument;
  \proc[]{insq-i} takes the interval as argument, and schedules the
  operation \code{interval} seconds after the current time.
\item The following arguments specify the object, \code{$obj},
  the instance procedure of that object, \code{$iproc},
  and the arguments to that procedure, \code{$args}.

  These arguments are placed into the route queue
  for execution at the appropriate time.
\end{list}

The instance procedure
\fcnref{\proc[]{runq}}{../ns-2/dynamics.tcl}{rtQueue::runq}
executes \code{eval $obj $iproc $args} at the appropriate instant.
After all the events for that instance are executed,
\proc[]{runq} will \proc[]{notify} each object about the execution.

Finally, the instance procedure
\fcnref{\proc[]{delq}}{../ns-2/dynamics.tcl}{rtQueue::delq}
can remove a queued action with the time and the name of the object.

\section{Interaction with Unicast Routing}
\label{sec:unicast-int}

In an earlier section,
we had described how
\href{unicast routing reacts}{Section}{sec:rtglibAPI}
to changes to the topology.
This section details the steps by which 
the network dynamics code will notify the nodes and routing
about the changes to the topology.
\begin{enumerate}
\item \proc[]{rtQueue::runq} will invoke the procedures
  specified by each of the route model instances.
  After all of the actions are completed,
  \proc[]{runq} will notify each of the models.
\item
  \fcnref{\proc[]{notify}}{../ns-2/dynamics.tcl}{rtModel::notify}
  will then invoke instance procedures at all of the nodes
  that were incident to the affected links.
  Each route model stores the list of nodes in its instance variable
  array, \code{nodes_}.

  It will then notify the RouteLogic instance of topology changes.
\item
  The rtModel object invokes the class Node instance procedure
  \fcnref{\proc[]{intf-changed}}{../ns-2/dynamics.tcl}{Node::intf-changed}
  for each of the affected nodes.
\item
  \proc[]{Node::intf-changed} will notify any \code{rtObject}
  at the node of the possible changes to the topology.

  Recall that these route objects are created when the simulation uses
  detailed dynamic unicast routing.
\end{enumerate}

\subsection{Extensions to Other Classes}
\label{sec:nd-extensions}

The existing classes assume that the topology is static by default.
In this section, we document the necessary changes to these
classes to support dynamic topologies.

We have already described the instance procedures
in the \clsref{Simulator}{../ns-2/ns-lib.tcl} to create or manipulate
route models, \ie,
\proc[]{rtmodel}, \proc[]{rtmodel-at}, \proc[]{rtmodel-delete}, and
\proc[]{rtmodel-configure} \href{in earlier sections}{Section}{sec:rtmodel}.
Similarly, the \clsref{Node}{../ns-2/ns-node.tcl}
contains the instance procedure \proc[]{intf-changed}
that we described in \href{the previous section}{Section}{sec:unicast-int}.

The network dynamics code operates on individual links.
Each model currently translates its specification into
operations on the appropriate links.
The following paragraphs describe the class Link and related classes.

\paragraph{\protect\clsref{DynamicLink}{../ns-2/dynalink.cc.tcl}}
This class is the only TclObject in the network dynamics code.
The shadow class is called \clsref{DynaLink}{../ns-2/dynalink.h}.
The class supports one bound variable, \code{status_}.
\code{status_} is 1 when the link is up, and 0 when the link is down.
The shadow object's \fcnref{\fcn[]{recv}}{../ns-2/dynalink.cc}{DynaLink::recv}
method checks the \code{status_} variable, to decide whether or not
a packet should be forwarded.

\paragraph{\protect\clsref{Link}{../ns-2/ns-link.tcl}}
This class supports the primitives:
up and down, and up? to set and query \code{status_}.
These primitives are instance procedures of the class.
\begin{list}{}{}
\item  The instance procedures
  \fcnref{\proc[]{up}}{../ns-2/dynamics.tcl}{Link::up} and
  \fcnref{\proc[]{down}}{../ns-2/dynamics.tcl}{Link::down}
  set \code{status_} to 1 and 0 respectively.

  In addition, when the link fails, \proc[]{down}
  will reset all connectors that make up the link.
  Each connector, including all queues and the delay object
  will flush and drop any packets that it currently stores.
  This emulates the packet drop due to link failure.

  Both procedures then write trace entries to each file handle
  in the list, \code{dynT_}.

\item The instance procedure
  \fcnref{\proc[]{up?}}{../ns-2/dynamics.tcl}{Link::up?}
  returns the current value of \code{status_}.
\end{list}
In addition, the class contains the instance procedure
\fcnref{\proc[]{all-connectors}}{../ns-2/dynamics.tcl}{Link::all-connectors}.
This procedure takes an operation as argument, and applies
the operation uniformly to all of the class instance variables
that are handles for TclObjects.

\paragraph{\protect\clsref{SimpleLink}{../ns-2/ns-link.tcl}}
The class supports two instance procedures
\fcnref{\proc[]{dynamic}}{../ns-2/dynamics.tcl}{SimpleLink::dynamic} and
\fcnref{\proc[]{trace-dynamics}}{../ns-2/dynamics.tcl}{SimpleLink::trace-dynamics}.
We have already described the latter procedure when describing the
\proc[]{trace} procedure in the class rtModel.

The instance procedure \proc[]{dynamic} inserts a 
\href{DynamicLink object}{Section}{sec:links:connectors}
at the head of the queue.
It points the down-target of the object to the 
drop target of the link, \code{drpT_}, if the object is defined,
or to the \code{nullAgent_} in the simulator.
It also signals each connector in the link that the link is now
dynamic.

Most connectors ignore this signal to be become dynamic;
the exception is \code{DelayLink} object.
This object will normally schedule each packet it receives
for reception by the destination node at the appropriate time.
When the link is dynamic, the object will queue each packet 
internally; it schedules only one event for the next packet
that will be delivered, instead of one event per packet normally.
If the link fails, the route model will signal a \code{reset},
at which point, the shadow object will execute its
\fcnref{reset instproc-like}{../ns-2/dynalink.cc}{DynaLink::command},
and flush all packets in its internal queue.
Additional details about the DelayLink can be found
\href{in another chapter}{Chapter}{chap:delays}.

\section{Deficencies in the Current Network Dynamics API}
\label{sec:deficiencies}

There are a number of deficencies in the current API that should be
changed in the next iteration:
\begin{enumerate}
\item  There is no way to specify a cluster of nodes or links that
behave in lock-step dynamic synchrony.
\item  Node failure should be dealt with as its own mechanism,
rather than a second grade citizen of link failure.
This shows up in a number of situations, such as:
\begin{enumerate}
\item  The method of emulating node failure as the failure of the
incident links is broken.  Ideally, node failure should cause all
agents incident on the node to be reset.
\item  There is no tracing associated with node failure.
\end{enumerate}
\item  If two distinct route models are applied to two separate links
incident on a common node, and the two links experience a topology change
at the same instant, then the node will be notified more than once.
\end{enumerate}



\section{Commands at a glance}
\label{sec:dynamicscommand}

Following is a list of commands used to simulate dynamic scenarios in \ns:

\begin{flushleft}
\code{$ns_ rtmodel <model> <model-params> <args>}\\
This command defines the dynamic model (currently implemented models are:
Deterministic, Exponential, Manual or Trace) to be applied to nodes and
links in the topology. The first two arguments consists of the rtmodel and
the parameter to configure the model. <args> stands for different type of
arguments expected with different dynamic model types. This returns a
handle to a model object corresponding to the specified model. 
\begin{itemize}
\item In the Deterministic model <model-params> is <start-time>, 
<up-interval>, <down-interval>, <finish-time>. Starting from start-time
the link is made up for up-interval and down for down-interval till
finish-time is reached. The default values for start-time, up-interval,
downinterval are 0.5s, 2.0s, 1.0s respectively. finishtime defaults to the
end of the simulation. The start-time defaults to 0.5s in order to let the
routing protocol computation quiesce. 

\item If the Exponential model is used model-params is of the form
<up-interval>, <down-interval> where the link up-time is an exponential
distribution around the mean upinterval and the link down-time is an
exponential distribution around the mean down-interval. Default values for
up-interval and down-interval are 10s and 1s respectively. 

\item If the Manual distribution is used model-params is <at> <op> where
at
specifies the time at which the operation op should occur. op is one of
up, down. The Manual distribution could be specified alternately using the
rtmodel-at method described later in the section. 

\item If Trace is specified as the model the link/node dynamics is read
from a
Tracefile. The model-params argument would in this case be the file-handle
of the Tracefile that has the dynamics information. The tracefile format
is identical to the trace output generated by the trace-dynamics link
method (see TRACE AND MONITORING METHODS SECTION). 
\end{itemize}


\code{$ns_ rtmodel-delete <model>}\\
This command takes the handle of the routemodel <model> as an argument,
removes  it from the list of rtmodels maintained by simulator and deletes
the model.


\code{$ns_ rtmodel-at  <at> <op> <args>}\\
This command is a special interface to the Manual model of network dynamics.
It takes the time <at>, type of operation <op> and node or link on which
to apply the operation <args> as the arguments. At time <at>, the operation <op>
which maybe up or down is applied to a node or link.

\code{$rtmodel trace <ns> <f> <optional:op>}\\
This enables tracing of dynamics effected by this model in the links. <ns>
is an instance of the simulator, <f> the output file to write the traces to
and <op> is an optional argument that may be used to define a type of
operation (like nam). This is a wrapper for the class Link procedure
\code{trace-dynamics}.


\code{$link trace-dynamics <ns> <f> <optional:op>}\\
This is a class link instance procedure that is used to setup tracing of
dynamics in that particular link. The arguments are same as that of class
rtModel's procedure \code{trace} described above.


\code{$link dynamic}\\
This command inserts a DynamicLink object at the head of the queue and signals
to all connectors in the link that the link is now dynamic.


Internal procedures:\\

\code{$ns_ rtmodel-configure}\\
This is an internal procedure that configures all dynamic models that are
present in the list of models maintained by the simulator.

\end{flushleft}

\endinput

### Local Variables:
### mode: latex
### comment-column: 60
### backup-by-copying-when-linked: t
### file-precious-flag: nil
### End: