I am very naive to NS2 use and was trying to implement CBR over UDP in NS2 and also TCP .
when i try to compile it it gives me this errors :
ns: _o28 start:
(_o28 cmd line 1)
invoked from within
"_o28 cmd start"
invoked from within
"catch "$self cmd $args" ret"
invoked from within
"if [catch "$self cmd $args" ret] {
set cls [$self info class]
global errorInfo
set savedInfo $errorInfo
error "error when calling class $cls: $args" $..."
(procedure "_o28" line 2)
(SplitObject unknown line 2)
invoked from within
"_o28 start"
this is my code ..i tried to fix it by looking on the internet but i did not get anything usefull
# Création du simulateur
set ns [new Simulator]
# Création des fichiers de traces NS-2
set nf [open out.nam w]
$ns namtrace-all $nf
$ns trace-all [open out1.tr w]
# Création des noeuds
set N1 [$ns node]
$N1 label "source cbr"
set N2 [$ns node]
$N2 label "source tcp"
set R1 [$ns node]
set R2 [$ns node]
set N3 [$ns node]
$N3 label "destination tcp"
set N4 [$ns node]
$N4 label "destination cbr"
#Setup a TCP connection
set tcp [new Agent/TCP]
$tcp set class_ 2
$ns attach-agent $N2 $tcp
set sink [new Agent/TCPSink]
$ns attach-agent $N3 $sink
$ns connect $tcp $sink
$tcp set fid_ 1
#Setup a FTP over TCP connection
set ftp [new Application/FTP]
$ftp attach-agent $tcp
$ftp set type_ FTP
#Setup a UDP connection
set udp [new Agent/UDP]
$ns attach-agent $N1 $udp
set null [new Agent/Null]
$ns attach-agent $N4 $null
$ns connect $udp $null
$udp set fid_ 2
#Setup a CBR over UDP connection
set cbr [new Application/Traffic/CBR]
$cbr attach-agent $udp
$cbr set type_ CBR
$cbr set packet_size_ 1000
$cbr set rate_ 1mb
$cbr set random_ false
# Création des liens, tous en 1Mbps/10ms de TR/file d'attente DropTail
$ns duplex-link $N1 $R1 10Mb 15ms DropTail
$ns duplex-link $N2 $R1 10Mb 15ms DropTail
$ns duplex-link $R1 $R2 5Mb 40ms DropTail
$ns duplex-link $R2 $N3 12Mb 15ms DropTail
$ns duplex-link $R2 $N4 6Mb 15ms DropTail
#capacité file d'attente R1-R2
$ns queue-limit $R1 $R2 50
# gestion du layout de la topologie
$ns duplex-link-op $R2 $N4 orient right-down
$ns duplex-link-op $R2 $N3 orient right-up
$ns duplex-link-op $R1 $R2 orient right
$ns duplex-link-op $N1 $R1 orient left-up
$ns duplex-link-op $N2 $R1 orient left-down
#$ns duplex-link-op $R1 $R2 queuePos 0.5 # voir l’état de la file
# Création d'un agent vide, destiné à recevoir les paquets implantés dans n3
set null0 [new Agent/Null]
$ns attach-agent $N3 $null0
# Création d'un agent vide, destiné à recevoir les paquets implantés dans n3
set tcpsink [new Agent/TCPSink]
$ns attach-agent $N4 $tcpsink
# Le traffic issu des agents udp0 et udp1 est envoyé vers null0
$ns connect $udp $null0
$ns connect $tcp $tcpsink
# Scénario de début et de fin de génération des paquets par cbr0
$ns at 0.0 "$cbr start"
$ns at 0.2 "$tcp start"
$ns at 4 "$tcp stop"
$ns at 5.0 "$cbr stop"
# Définition de classes pour la coloration
# Coloration des classes : bleu pour udp (classe 1) et rouge pour tcp (classe 2)
$ns color 1 Blue
$ns color 2 Red
# Procédure de fin de simulation, qui écrit les données dans le fichier
# et lance NAM pour la visualisation
proc fin {} {
global ns nf
$ns flush-trace
close $nf
exec nam out.nam &
exit 0
}
# La simulation va durer 15 secondes et appelle la procédure finish
$ns at 6.0 "fin"
# Début de la simulation
$ns run
NS2 is built on top of an object system written in Tcl called OTcl. It's a rather old system now; everyone else in Tcl (who uses an object system at all) uses something else. One of the reasons for this is that debugging OTcl programs is rather more awkward than for most Tcl programs.
But that doesn't deal with the issue here! If we look at that stack trace, we can pick our way back from the call that kicks it off:
"_o28 start"
to the place where the error pops into view:
(_o28 cmd line 1)
Alas, everything in-between is just OTcl machinery. It's nasty to my eyes, as I notice a number of bad practices within it, but it shouldn't concern you: it's not in your code, but rather the library that you're using.
Unfortunately, whatever created the error didn't bother to give us an error message! That's terrible. However, we can guess from the method name that it is one of these lines that calls it (delayed until the simulator engine reaches that timestamp):
$ns at 0.0 "$cbr start"
$ns at 0.2 "$tcp start"
Which is it? The start method of the Application/Traffic/CBR class or of the Agent/TCP class? I really don't know! The stack trace neatly omits that. The method definitions aren't shown in your code sample, and might actually be in C or C++. We simply don't have the information. We do know that it looks like it is coming from the first line of that start method body, but that's about all.
Since you are using global variables, you can (probably) change those two callback setup lines to do this:
$ns at 0.0 {$cbr start}
$ns at 0.2 {$tcp start}
This postpones the substitution of the variable until call time, and might make your stack trace informative enough to work out which class's start method has the problem. It won't fix the problem, but it might let you hunt it more easily.
Generally, your code seems reasonable Tcl. It's using NS2 so it is also using OTcl (alas) but otherwise it is not a problem. Modern Tcl programming prefers to use the list command to construct callbacks instead of string substitution, so you might do this:
$ns at 0.0 [list $cbr start]
$ns at 0.2 [list $tcp start]
instead of this:
$ns at 0.0 "$cbr start"
$ns at 0.2 "$tcp start"
But object names are simple and these are one-off callbacks so it won't have much effect on safety or performance.
I can't tell you if you are using NS2 correctly. I write very different Tcl programs using totally different libraries.