Re: how to only enable some node to use multiPath?

[Lloyd Wood <L.Wood@surrey.ac.uk>]

On Tue, 9 Nov 1999, Guo, Liang wrote:

> I want to only enable some nodes in the network to be able to
> use multiPath (while others are not), according to NS document,
> I should do something like:
> 
> set n1 [$ns Node]
> $n1 set multiPath_ 1
> 
> however, these doesn't work, seems that "multiPath_" setting
> can only be applied to all or none. Is that true? 

Shouldn't be the case; the documentation on that hasn't changed for
well over a year, and the stuff in ~ns/tcl/lib/ns-node.tcl looks okay. 
Try:

Node set multiPath_ 1
set n1 [$ns Node]   ;# this node should be multipath-aware
Node set multiPath_ 0
set n2 [$ns Node]   ;# this node shouldn't be

etc. as a workaround, since that ought to work even in the new node
API, whereas I'm no longer at all sure about the other method.

(you do need DV routing to boot.  multipath as an option with god-mode
 perfect routing would be nice.)


> If so, how to modify the code to enable partial "multiPath_" setting?

Should be working without modification already; examine the instprocs
in ~ns/tcl/lib/ns-node.tcl.

Actually, this I-only-want-it-partially problem applies to a large
number of bound variables use for global settings, where you want
global default values, but settable per-node or per-link values - so
the node will inherit the global value, but it can be explicitly
overriden on a per-node basis. (okay, multiPath is handled in Tcl and
only looks_ like a bound variable.)

This is something I was suggesting to Tom for the large number of
bound global variables settable in OTcl that were introduced by the
satellite code, because you'd e.g. want to set elevation_mask_ on a
per-terminal basis, and not globally for all terminals via:

HandoffManager/Term set elevation_mask_ 40

(or the sort of thing you find in  tcl/ex/wireless-demo-csci694.tcl)

yet rewriting all the methods to handle each new variable (a la done
for multiPath) is a pain, and there's a tradeoff against simplicity of
binding a single variable (often the current approach), too.

looking at the sort of thing you find in
tcl/ex/wireless-demo-csci694.tcl, am I correct in thinking that you
would eventually implement such new variables under the new

$ns_ node-config OPTION_TYPE AVAILABLE_OPTION_VALUE 

instead, or am I way off base class here?

thanks,

L.

<L.Wood@surrey.ac.uk>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>