srm.txt

跑leach需要的

#
# Copyright (C) 1997 by USC/ISI
# All rights reserved.                                            
#                                                                
# Redistribution and use in source and binary forms are permitted
# provided that the above copyright notice and this paragraph are
# duplicated in all such forms and that any documentation, advertising
# materials, and other materials related to such distribution and use
# acknowledge that the software was developed by the University of
# Southern California, Information Sciences Institute.  The name of the
# University may not be used to endorse or promote products derived from
# this software without specific prior written permission.
# 
# THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
# WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.
# 

#
# Maintainer: Kannan Varadhan <[e-mail]>
# Version Date: $Date: 1997/10/23 20:53:36 $
#
# @(#) $Header: /nfs/jade/vint/CVSROOT/ns-2/tcl/ex/srm.txt,v 1.8 1997/10/23 20:53:36 kannan Exp $ (USC/ISI)
#

There are five example scripts to demonstrate the implementation of SRM.
These are srm-star.tcl, srm-chain.tcl, srm.tcl, srm-adapt-req.tcl, and
srm-adapt-rep.tcl.  When the results from each of these scripts is viewed in
nam, data traffic is coloured white, traffic from the source is coloured
blue, and traffic from the the receivers is multi-coloured in various shades
of red.  (Tiny packets are requests, slightly larger packets are session
messages, and large colored packets are repairs.)

Traffic from the source consists of session messages, and repairs.
Traffic from the receivers is session messages, requests, and
(occasionally) repairs.

In order to make viewing protocol behaviour more intuitive in nam, these
scripts source ../mcast/srm-nam.tcl.  This script modifies the messages
classes, to achieve the desired colouring described earlier.  Dense mode
traffic, such as joins and prunes, where applicable, are coloured black.
Data traffic is white (the good guys, see? :-) In addition, requests are
normally teensy weensy packets (about 12 bytes long), session messages are
medium sized, and data packets are relatively hugish.

In addition, sources are square, leaf nodes are circle, transit nodes
are hexagonal.  In general, all nodes are members of the group.  The
exception is the star topology, in which the central node is not.

(NB:  If DM multicasting is used, then expect to send periodic prunes
and joins as explicit messages).

Example 1: srm-chain.tcl is chain topology, with a CBR source at node 0.
All the nodes join the group at time t =~ 1.0s.  They take another 3.0s
to determine distances to all other group members.  The traffic
generator starts at 3.5s.  A single packet drop is created through link
dynamics (the link is toggled momentarily using one of the route
models) at 3.52s.

Example 2: srm-star.tcl is a star topology, with identical parameters
to the earlier chain topology.  You can vary the number of nodes in the
topology by editing srm_star.tcl.  However, the nam config file is
written for a 8 (+1) node topology.

Example 3:  srm.tcl is a Y topology, with the source at the
center, and receivers at each of the arms.  The data source is an
exponential traffic generator (see tg.txt, tg.tcl for additional
details).  The traffic generator directly feeds the srm agent.  (This
is unlike earlier situations where the traffic generator feeds the node
directly).  Data generation starts at 0.5s.  Nodes 1, 2, and 3 join at
1.0s., 1.1s., and 1.2s respectively.  As each node comes up, it
requests the initial sequence of data from the source that it is
currently missing.  Request messages will start appearing after about
3s.  because the nodes have not computed distances to each other
accurately yet.

Example 4, 5: srm-adapt-re[pq].tcl is a 8 node topology, identical to
srm-star.tcl.  The simulation runs for 50s.  In the -req, the link
incident to the source fails periodically, causing data packets to be
dropped.  This causes request parameter adaptation in all the other
receivers.  The -rep form is the dual in which one of the receivers
experiences the loss, and all the other members adapt their repair
parameters to respond to this loss.  The default situation uses
Adaptive timers, but can be setup to use Fixed timers by specifying it
as a command line option (for e.g. ``../../ns srm-adapt-rep.tcl Fixed'').
This allows us to compare adaptive timers with other types of timers
(such as Fixed timers) in identical scenarios.

In each of the examples, output statistics is written out to
srmStats.tr.   Detailed event trace files are written to srmEvents.tr.
Source srm-debug.tcl if you want to see additional details of the delay
computation functions.