Re: Quick question about mcast routing

[Yuri Pryadkin <yuri@who.isi.edu>]

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