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

a clue to multicast addressing weirdness



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"