[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: a clue to multicast addressing weirdness

To: Padmaparna Haldar <[email protected]>
Subject: Re: a clue to multicast addressing weirdness
From: Lloyd Wood <[email protected]>
Date: Tue, 12 Jan 1999 20:25:13 +0000 (GMT)
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Organization: speaking for none
Reply-To: Lloyd Wood <[email protected]>

On Tue, 12 Jan 1999, Padmaparna Haldar wrote:

> Hi Lloyd,
>          Node expandaddr and set-address-format expanded are not
> equivalent, as the note in ns-address.tcl says:
> 
> #####################################################################
> # IMPORTANT NOTE: Always use "Node expandaddr" to expand addresses
> # instead of "$ns set-address-format expanded". the set-addr-format 
> # is called internally and doesnot check for mcast or hier flags and 
> # thus can result in errors. Hence "$ns set-address-format expanded" 
> # should
> # *not* be used as a replacement API for "Node expandaddr", 
> # especially for multicast simulations.
> #####################################################################


(blink blink) First off: what note?

$ grep expandaddr tcl/lib/ns-address.tcl
$

$ grep expandaddr tcl/lib/*.tcl
$

The note you describe is _not_ in tcl/lib/ns-address.tcl (or any other
lib .tcl file) of the ns daily snapshot. It's not in same in ns 2.1b4.

(Are you looking at notes in your CVS tree not visible to external
 users? Or at a much older ns?) 


> The above two methods perhaps should be merged to avoid confusion.

Most definitely, although the recent ns-address.tcl *I'm* looking at
seems to suggest by omission that expandaddr is no longer used, not
that it's actually the recommended choice. Are comments optimistically
running ahead of code here? 

(btw, have you guys considered making read-only access to your CVS
 tree public a la mozilla? If you're assuming I've read stuff that I
 can't even find, you may as well make it visible...)


> BTW, I remember having written to you about this very issue several
> months back..

We have discussed hierarchical addressing, and you implemented a
bugfix providing support for a single level. We also discussed use of
Node allocaddr - you pointed out that turning on expanded addressing
breaks a number of example multicast scripts in the distribution
because they had to allocate specific (low) group numbers, which I'd
missed when wondering why multicast failed with expanded addressing -
while citing those scripts erroneously as example cases supporting my
problem.

I don't have anything in my mail archives from you relating to using
Node expandaddr instead of set-address-format. Got a message-ID on
that?


> anyways, hope this helps,

It certainly explains observed behaviour in a number of cases. thanks.
now, if only I'd read that six months ago...

L.

back to trying to move the core.

> --Padma. 
> 
> 
> 
> 
> On Tue, 12 Jan 1999, Lloyd Wood wrote:
> 
> > Today (11 January 1999) I grabbed and built all the daily snapshots.
> > 
> > As I reported previously several times last year, I have an
> > interesting problem[*] involving my simulation scripts, large
> > addressing spaces and multicast, and I now believe that if I haven't
> > tracked down the cause of the problem, I've at least found a
> > repeatable symptom. 
> > 
> > This could make a very nice change - eliminating it will probably help
> > me track down any other remaining problems...
> > 
> > To wit; setting expanded address space in my scripts with:
> >   Node expandaddr
> > currently works just fine and dandy with the ns snapshot, even for
> > some stupidly large simulation topologies I'd probably be better off
> > running under SessionSim rather than the normal Simulator. (circa 600
> > multicast nodes.)
> > 
> > Replacing that single 'Node expandaddr' line in my scripts with the
> > more fashionable, recent and apparently equivalent:
> >   $ns set-address-format expanded
> > causes a segmentation fault that even tcl-debug can't catch. All the
> > time. [irrespective of setting old flags or doing the new -multicast
> > lines below].
> > 
> > I can repeat this behaviour with nam-example.tcl:
> > 
> > > ns nam-example.tcl 
> > Flag variable Simulator::EnableMcast_ discontinued.
> >          Use multicast methods as:
> >                  % set ns [new Simulator -multicast on]
> >                  % $ns multicast
> > running nam...
> > 
> > the current nam-example.tcl uses Node expandaddr. If I change that
> > line of nam-example.tcl to read
> >    $ns set-address-format expanded
> > and modify the script as suggested, I get the legendary and completely
> > inscrutable[*]
> > _o19: no target for slot 128
> > that I previously been reported a couple of times last year.
> > 
> > Go back to Node expandaddr and the slot target error is vanquished -
> > Hurrah! ['$ns set-address-format hierarchical 1 12' fails similarly
> > to expanded for the example code and for my scripts.]
> > 
> > Right, so 'Node expandaddr' and '$ns set-address-format'
> > don't appear to be behaving in any equivalent fashion whatsoever; I
> > don't understand why the new clasy form fails. And I'm convinced that
> > it really isn't my fault.
> > 
> > Node expandaddr seems to work for me. I like it.
> > 
> > Anyone? The actual multicast traffic part of my script 
> > ns/lloyd/traffic/simplemcast.tcl
> > is below; I'm using CtrMcast.
> > 
> > thanks,
> > 
> > L.
> > 
> > [*] well, to me, anyway.
> > oh yes: http://www-mash.cs.berkeley.edu/ns/mcast.html
> > have any changes been accomplished since last June? TIA.
> > 
> > <[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>
> > 
> > 
> > # Pick multicast type for all nodes e.g. 
> > # set mproto DM
> > # set mproto dynamicDM
> > # set mproto CtrMcast
> > 
> > set mproto CtrMcast
> > 
> > set group [Node allocaddr]
> > 
> > # set all nodes to be multicast nodes
> > set mrthandle [$ns mrtproto $mproto {} ]
> > 
> > # simple graphics test - set up a simple multicast group
> > 
> > $mrthandle switch-treetype $group
> > $mrthandle compute-mroutes
> > 
> > set m5 [new Agent/LossMonitor]
> > $ns attach-agent $g(5) $m5
> > 
> > set m12 [new Agent/LossMonitor]
> > $ns attach-agent $g(5) $m12
> > 
> > set udp0 [new Agent/UDP]
> > $ns attach-agent $g(1) $udp0
> > $udp0 set dst_ $group
> > 
> > set cbr0 [new Application/Traffic/CBR]
> > $cbr0 attach-agent $udp0
> > $udp0 set fid_ 1
> > $ns color 1 Red
> > 
> > # setting the central router doesn't work
> > # $mrthandle set-c-rp { n(20) }
> > # debug 1
> > 
> > $ns at 0.1 "$cbr0 start"
> > $ns at 1.0 "$g(5) join-group $m5 $group"
> > $mrthandle compute-mroutes
> > $ns at 2.0 "$g(12) join-group $m12 $group"
> > $mrthandle compute-mroutes
> > $ns at 3.0 "$g(32) join-group $m12 $group"
> > $mrthandle compute-mroutes
> > $ns at 4.0 "$g(44) join-group $m12 $group"
> > $mrthandle compute-mroutes
> > $ns at 5.5 "$g(32) leave-group $m12 $group"
> > $mrthandle compute-mroutes
> > 
> > $ns at 10.0 "finish"
> 
> ------------------------------------------------
> Be true to your work, your word, and your friend.
> --Thoreau
> 
> Padmaparna Haldar
> ISI/USC.
> 310.822.1511 #352

<[email protected]>PGP<http://www.ee.surrey.ac.uk/Personal/L.Wood/>

References:
- Re: a clue to multicast addressing weirdness
  - From: Padmaparna Haldar <[email protected]>

Prev by Date: Re: a clue to multicast addressing weirdness
Next by Date: Re: Yonghwan Kim: Questions on another "NS workshop".
Prev by thread: Re: a clue to multicast addressing weirdness
Next by thread: error-module with 802.11, not proper
Index(es):
- Date
- Thread