Re: Quick question about mcast routing

[christos@ccrc.wustl.edu]

Yuri, John,

thanks for your suggestions. I ended up doing something a bit
different, please let me know what you think.

To recap, I was interested in creating a list with all the links
belonging to a multicast tree routed on a specific source. I assume DM
as the mcast routing protocol, which essentially uses the unicast
routing table to create the RPF tree.

What I did is to start from each receiver, and use the proc
upstream-node to traverse the RPF tree back to the source, adding the
forward link into the list of links. It goes something like this:

set tree_links ""
proc gather-tree-links { nid sid } {
        global ns tree_links

        if { $nid == $sid } {
                return
        }
        set ups [[$ns upstream-node $nid $sid] set id_]
        if { [lsearch -exact $tree_links [list $ups $nid]] < 0 } {
                lappend tree_links [list $ups $nid]
                gather-tree-links $ups $sid
        }
} 

proc make-tree-links { sid } {
        global n rcvrnum

        for {set i 0} { $i <= $rcvrnum} {incr i} {
            gather-tree-links [$n($i) set id_] $sid
        }
}

and then:

$ns at  $setup_time "make-tree-links [$src set id_]"

It seems to work.

Christos.


------------ Yuri Pryadkin writes:
  > 
  > John Heidemann <johnh@ISI.EDU> writes:
  > 
  > > On 08 Feb 1999 09:43:41 PST, Yuri Pryadkin wrote: 
  > > >christos@ccrc.wustl.edu writes:
  > > >
  > > >> Hi everyone,
  > > >> 
  > > >> is there a quick way to discover the links belonging to
  > > >> a multicast tree created by DM?
  > > >> 
  > > >> Christos.
  > > >
  > > >If this link is i->j, you'll need to check if the head of the link is
  > > >an active target in any of i's replicators.  Something like this
  > > >(untested) :
  > > >
  > > >DM instproc mcast-link {i j} {
  > > >	$self instvar ns_
  > > >	set head [[$ns_ link $i $j] head]
  > > >	foreach rep [$i getReps "*" "*"] {
  > > >		if { [$rep is-active-target $head] } {
  > > >			return 1;
  > > >		}
  > > >	}
  > > >	return 0
  > > >}
  > > >
  > > >Since mcast uses bi-directional links, you'll have to check both
  > > >directions.
  > > 
  > > Something like this probably works, but checking the head of the link
  > > is not very portable.  In general code shouldn't depend on ordering of
  > > the modules on the link since that ordering may change.  For example,
  > > one might add a trace object at the head of the link.
  > 
  > I believe it is portable because:
  > 
  > 	1.  the head of the link is fixed to be a dedicated connector
  > and whatever objects are added to the link are supposed to be inserted
  > *after* this connector (this is true for current snapshot); a special
  > method is provided for that $link add-to-head <...>
  > 
  > 	2.  Generally, even if it were not so, it doesn't make much
  > sense to change a head of a link in the middle of simulation (i.e. at
  > the time you're running this instproc and after multicast protocol has
  > installed those heads-of-links in replicators).  If you do something
  > like this, those objects will be bypassed anyways.  Note, that the
  > code above doesn't make any assumptions about what object the head of
  > the link is.
  > 
  > Cheers,
  > 
  >  -Yuri
  >