Re: [ns] Object instantiation of C++ classes in ns: where and when?
Claus Christmann wrote:
> I apologize for the monologue, but I still have some issues with
> *object instantiation of C++ classes in ns*
>
> I read up on inherited classes and according to the book the constructor
> of a base class is called when an object of an inherited class is
> instantiated. Example:
>
> class animal
> {
> public:
> aninmal(){cout<<"making an animal"< ~animal(){cout<<"unmaking an animal"< };
>
> class dog: public animal
> {
> public:
> dog(){cout<<"making a dog"< ~dog(){cout<<"making a dog"< };
>
> int main()
> {
> dog * bello = new dog;
> cout<< " blah ..." < delete bello; bello = 0;
> return 0;
> }
>
> (should) lead to the following output:
> making an animal
> making a dog
> blah ...
> unmaking a dog
> unmaking an animal
>
> So the questions remain:
>
> a) What happens in the mw-node code with the WirelessRoutingModule()
> constructor? Why doesn't it seem to be called?
It is called. Print out some text in the constructor to convince you.
>
> b) The constructor only calls init(), declared virtual function in
> WirelessRoutingModule. Since BaseWirelessRoutingModule (derived from the
> former) also has a init() function, the WirelessRoutingModule()
> constructor should call the init() of BaseWirelessRoutingModule,
> shouldn't it?
>
No it should not. This is because by default the parent constructor
(here WirelessRoutingModule()) is called before the child constructor
when the child constructor is called (here BaseWirelessRoutingModule()).
In your example above, new dog() results in making an animal, making a
dog and not in making a dog, making an animal.
In the parent constructor, the child object is not created yet and if a
function is called it is a parent's function (print out some text in
WirelessRoutingModule::init() to convince you).
If you want to call BaseWirelessRoutingModule::init() when you create
the object you have to call it in BaseWirelessRoutingModule().
-Laurent
> c) Resulting from that I followed Pedro's guide to get oTcl debugging
> capabilities, but I couldn't get it to run with the mw-node patch. The
> MASH inspector always kills ns with a segmentation fault when tryin gto
> inspect a WirelessRoutingModule oTcl object. Anybody having some input
> on that?
>
> I apologize for this series of long emails, but somehow it seems that
> there is some basic issues of C++/oTcl/ns2 which I do not understand.
>
> Thanks in advance for any comment.
>
> Claus
>
>
> Claus Christmann wrote:
>> OK, my mistake...
>>
>> BaseWirelessRouting module is derived from WirelessRoutingModule, but
>> constructors and destructors are not inherited. (Which is a basic C++
>> behavior...)
>>
>> Hence there is no constructor or destructor explicitly given and thus
>> (an empyt) one is created. This auto generated constructor obviously
>> does not call BaseWirelessRoutingModule::init() .
>>
>> Sorry for all the fuzz...
>>
>> Claus
>>
>>
>> Claus Christmann wrote:
>>> Hi list,
>>>
>>> I am working with Laurent's mw-node patch
>>> (http://www.q2s.ntnu.no/~paquerea/ns.html) and am trying to get my own
>>> routing protocol to work.
>>>
>>> Since my routing protocol utilizes several wirelss interfaces it should
>>> be implemented as a WirelessRoutingModule akording to Laurent's
>>> documentation. Unfortunately the constructor for this class seems to be
>>> never called. I assume that is due to the oTcl/C++ duality, which I seem
>>> to be unable to debug.
>>>
>>> The code under consideration is in wireless/wireless-rtmodule.cc, lines
>>> 84pp:
>>>
>>> //! Constructor
>>> /*! Create a new WirelessRoutingModule with an empty routing information
>>> base.*/
>>> WirelessRoutingModule::WirelessRoutingModule()
>>> : RoutingModule(),lastUid_(-1),lastRibEntry_(0)
>>> {
>>> rib_ = new Rib();
>>> init();
>>> }
>>>
>>> This C++ class is used as a parent later on
>>> (wireless/wirelss-rtmodule.h, lines 173pp):
>>>
>>> class BaseWirelessRoutingModule : public WirelessRoutingModule {
>>> ...
>>> }
>>>
>>> and BaseWirelssRoutingModule is used in the example provided with the
>>> patch. Unfortunately BaseWirelessRoutingModule does not do anything in
>>> init() (wireless/wireless-rtmodule.cc, lines 488pp)
>>>
>>> void
>>> BaseWirelessRoutingModule::init()
>>> {
>>> // nothing to do.
>>> }
>>>
>>> Thus it seemes not to matter, that at least using the provided tcl
>>> script it seems never to be called.
>>>
>>> Am I doing somthing wrong in gdb?
>>> *How is it possible that the constructor of a used class is never called?*
>>>
>>> Has anybody any experience in coding a routing protocol for the MW-node
>>> patch or could point me to a source to look at?
>>>
>>> Thanks in advance,
>>>
>>> Claus
>>>
>>>
>
Re: [ns] Phy/WirelessPhy Segmentation Fault
For the same exact reason that it happens with a non-patched version of ns-2.30 (i.e. this is not related with the MW-Node patch). You need a Simulator instance. Try simply % new Simulator % set phy_a [new Phy/WirelessPhy] You should not get any segmentation fault. Laurent Paquereau Q2S Centre of Excellence, NTNU Elena Putzolu wrote: > hi ns-users, > > I work with ns-2.30 and Mw-Node patch (for interfaces/multiple channels). > > When I try to write in ns: > > % set phy_a [new Phy/WirelessPhy] > the result is: Segmentation Fault. > > Someone knows to tell me, why happens this? > > Any help would be highly appreciated. > Thanks > Elena > > > > >
Re: [ns] my script MW-node
If I run exactly your script (only removing $eilastlevelSecondo which is
undefined) with ns-2.30-allinone and the latest version of the patch
(20070301) I do not get such an error. The message indicates an error
when you create the first wireless interface on node_AP(0). It is as if
you had written "new Phy/WirelessPhy]". Maybe you modified
ns-wireless.tcl? Does the mwnode test pass?
Note also that the way you have written your script all the interfaces
have the same configuration val_b(phy/mac). For example,
$val_b(mac) set SlotTime_ ... and $val_a(mac) set SlotTime_ modify the
same static tcl variable because val_a(...) and val_b(...) are equal.
You do not actually need these variables but you need to change the
static variables at the right place (create the interfaces with one
configuration and then change it before you create the interfaces with a
different mac/phy configuration.
Note that all this is not related to the MW-Node in particular.
Laurent Paquereau
Q2S Centre of Excellence, NTNU
Elena Putzolu wrote:
> Hi Laurent,
> Thank you very much for the answer, I have changed my script, but
> doesn't work.
> According to you, because I from this type of mistake?
>
> ns: new BiConnector/NetworkInterface2/FullStack/Wireless 0 _o21 _o33:
> invalid command name "Phy/WirelessPhy]"
> while executing
> "Phy/WirelessPhy] create _o37 "
> invoked from within
> "catch "$className create $o $args" msg"
> invoked from within
> "if [catch "$className create $o $args" msg] {
> if [string match "__FAILED_SHADOW_OBJECT_" $msg] {
> delete $o
> return ""
> }
> global errorInfo
> error "class $..."
> (procedure "new" line 3)
> invoked from within
> "new [WirelessModule set wireless_param_(phy)]"
> (procedure "_o36" line 11)
> (BiConnector/NetworkInterface2/FullStack/ init line 11)
> invoked from within
> "_o36 init 0 _o21 _o33"
> (Class create line 1)
> invoked from within
> "BiConnector/NetworkInterface2/FullStack/Wireless create _o36 0 _o21 _o33"
> invoked from within
> "catch "$className create $o $args" msg"
> invoked from within
> "if [catch "$className create $o $args" msg] {
> if [string match "__FAILED_SHADOW_OBJECT_" $msg] {
> delete $o
> return ""
> }
> global errorInfo
> error "class $..."
> (procedure "new" line 3)
> invoked from within
> "new BiConnector/NetworkInterface2/FullStack/Wireless 0 _o21 _o33"
>
>
> My Script:
> global val_
> global val_a
> global val_b
> set val_(channel)Channel/Wireless;# channel
> set val_(propagation) Propagation/TwoRayGround ;# radio-propagation model
>
> set val_a(phy) Phy/WirelessPhy ;# physical layer
> set val_b(phy) Phy/WirelessPhy ;# physical layer
>
> set val_a(mac) Mac/802_11 ;# mac layer
> set val_b(mac) Mac/802_11 ;# mac layer
>
> set val_(ifq) Queue/DropTail/PriQueue ;# interface
> queue type
> set val_(ll) LL;# link layer type
> set val_(antenna) Antenna/OmniAntenna ;# antenna model
> set val_(ifqlen) 50;# max packet in ifq
>
> set val_(routing) InterfaceWirelessRoutingProtocol ;# routing
>
> set val_(x)150
> set val_(y)150
> set val_(tr) esercizi/out4.tr;# trace file
> set val_(namtr)esercizi/out4.nam ;# nam trace file
> set val_(stopTime) 15
>
> set chan_a [new $val_(channel)]
> set chan_b [new $val_(channel)]
>
> proc init {} {
> global val_ tracefd_ namfd_ ns_
> set ns_ [new Simulator]
> set tracefd_ [open ./$val_(tr) w]
> $ns_ trace-all $tracefd_
> set namfd_ [open ./$val_(namtr) w]
> $ns_ namtrace-all-wireless $namfd_ $val_(x) $val_(y)
> }
>
> proc finish {} {
> global val_ tracefd_ namfd_ ns_ node_
> for {set i 0} {$i < $val_(nMn) } {incr i} {
> $ns_ at $val_(stopTime) "$node_($i) reset"
> }
> $ns_ flush-trace
> close $tracefd_
> close $namfd_
> exit 0
> }
>
> global ns_
>
> init
>
>
> $val_a(mac) set SlotTime_ 0.50;# 50us
> $val_a(mac) set SIFS_ 0.28;# 28us
> $val_a(mac) set PreambleLength_0 ;# no preamble_
> $val_a(mac) set PLCPHeaderLength_ 128;# 128 bits
>
Re: [ns] I neeh help for my script with MW-node patch
Elena,
What you are doing here is setting each interface on a different channel
so no packet will be received.
If I understand correctly what you are trying to do, first create your
two channels and then configure the interfaces on the correct channels.
Another hint is to configure all the interfaces on one channel first and
then all the interfaces on the other; it makes it simpler to
understand. Finally you do not need to use node-config and
wireless-config each time if the configuration of two or more
nodes/interfaces is identical (e.g. your 3 mobile nodes). Using loops in
this case also simplifies the script.
Laurent Paquereau
Q2S Centre of Excellence, NTNU
Elena Putzolu wrote:
Hi ns-users,
I have installed in ns-2.30 patch MW-node,
http://www.q2s.ntnu.no/~paquerea/ns.html
through my script, would purely like to simulate a net wireless, where
presents of Access Point (2) and the mobile nodes(3). Access Point
communicate between them through the standard 802.11a, while the mobile
nodes only communicate cross Access Point with the standard 802.11b/gm.
Therefore Access Point need 2 interfaces with different settings (
802.11a, 802.11b/g ) using pach and the commands I have found in the
manual tried to set up all these elements in my script:
global val_
set val_(channel)Channel/Wireless;# channel
set val_(propagation) Propagation/TwoRayGround ;# radio-propagation model
set val_a(phy) Phy/WirelessPhy ;# physical layer
set val_b(phy) Phy/WirelessPhy ;# physical layer
set val_a(mac) Mac/802_11 ;# mac layer
set val_b(mac) Mac/802_11 ;# mac layer
set val_(ifq) Queue/DropTail/PriQueue ;# interface
queue type
set val_(ll) LL ;# link layer type
set val_(antenna) Antenna/OmniAntenna ;# antenna model
set val_(ifqlen) 50 ;# max packet in ifq
set val_(routing) InterfaceWirelessRoutingProtocol ;# routing
set val_(x)150
set val_(y)150
set val_(tr) esercizi/out4.tr ;#
trace file
set val_(namtr)esercizi/out4.nam ;# nam
trace file
set val_(stopTime) 15
proc init {} {
global val_ tracefd_ namfd_ ns_
set ns_ [new Simulator]
set tracefd_ [open ./$val_(tr) w]
$ns_ trace-all $tracefd_
set namfd_ [open ./$val_(namtr) w]
$ns_ namtrace-all-wireless $namfd_ $val_(x) $val_(y)
}
proc finish {} {
global val_ tracefd_ namfd_ ns_ node_
for {set i 0} {$i < $val_(nMn) } {incr i} {
$ns_ at $val_(stopTime) "$node_($i) reset"
}
$ns_ flush-trace
close $tracefd_
close $namfd_
exit 0
}
global ns_
init
$val_a(mac) set SlotTime_ 0.50;# 50us
$val_a(mac) set SIFS_ 0.28;# 28us
$val_a(mac) set PreambleLength_0 ;# no preamble_
$val_a(mac) set PLCPHeaderLength_ 128 ;# 128 bits
$val_a(mac) set PLCPDataRate_ 1.0e6 ;# 1Mbps
$val_a(mac) set dataRate_ 54.0e6 ;# 54Mbps
$val_a(mac) set basicRate_ 1.0e6 ;# 1Mbps
###802.11b/g
$val_b(mac) set SlotTime_ 0.20;# 20us
$val_b(mac) set SIFS_ 0.10;# 10us
$val_b(mac) set PreambleLength_144 ;# 144 bits
preamble
$val_b(mac) set PLCPHeaderLength_ 48 ;# 48 bits
$val_b(mac) set PLCPDataRate_ 1.0e6 ;# 1Mbps
$val_b(mac) set dataRate_ 11.0e6 ;# 11Mbps or
54Mbps(802.11g)
$val_b(mac) set basicRate_ 1.0e6 ;# 1Mbps
$val_a(phy) set Pr_ 8.9175e-10
$val_a(phy) set Pt_ 0.2818
$val_a(phy) set freq_ 5.0e+9
# Receive sensitivity.
#./threshold.out -m TwoRayGround -r 0.95 -Pt 0.2818 -Gt 1 -Gr 1 -fr
5.0e+9 200; Calcola RXThresh_
$val_a(phy) set RXThresh_ 1.60607e-10
$val_a(phy) set CSThresh_ [expr 0.9*[$val_a(phy) set RXThresh_]]
$val_b(phy) set Pr_ 8.9175e-10
$val_b(phy) set Pt_ 0.007214
$val_b(phy) set freq_ 2.4e+9
$val_b(phy) set RXThresh_ 7.138e-11
$val_b(phy) set CSThresh_ [expr 0.9*[$val_b(phy) set RXThresh_]]
## 802.11g
$val_b(phy) set DSSS_CWMin 15
$val_b(phy) set DSSS_CWMax 1023
$val_b(phy) set DSSS_SlotTime 0.09
$val_b(phy) set DSSS_CCATime 0.03
$val_b(phy) set DSSS_RxTxTurnaroundTime 0.02
$val_b(phy) set DSSS_SIFSTime 0.16
$val_b(phy) set DSSS_PreambleLength 96
Re: [ns] error while executing mwnode-ex.tcl
http://mailman.isi.edu/pipermail/ns-users/2007-March/059031.html
After applying a patch to a source code, you need to recompile... Run
make and it will work.
For the detailed sequence of commands to run:
http://www.q2s.ntnu.no/~paquerea/ns.html
Laurent Paquereau
Q2S Centre of Excellence, NTNU
Raja Zahilah Raja Mohd. Radzi wrote:
> Hi all,
>
> I have copied ns-2.30.patch in folder ns-2.30.
> Then patch it...as in your website.
> Then ./configure
> Then ./validate
> When i run >>ns mwnode-ex.tcl , i got errors:
>
> invalid command name "Channel/Wireless"
> while executing
> "Channel/Wireless create _o14 "
> invoked from within
> "catch "$className create $o $args" msg"
> invoked from within
> "if [catch "$className create $o $args" msg] {
> if [string match "__FAILED_SHADOW_OBJECT_" $msg] {
> delete $o
> return ""
> }
> global errorInfo
> error "class $..."
> (procedure "new" line 3)
> invoked from within
> "new $val_(channel)"
> invoked from within
> "$ns_ wireless-config-routing$val_(routing) \
> -mac$val_(mac) \
> -phy..."
> (file "mwnode-ex.tcl" line 86)
>
> Anybody can help me with this..?
Re: [ns] problem with MW-Node patch for ns-2
If test-all-mwnode pass, the example should work as well.
Ensure you use the latest version of the patch and ensure you have
properly _reinstall_ ns after applying the patch
(configure, make distclean, configure, make).
Then test for example:
$ns
% new Channel/Wireless
If you have applied the patch and reinstalled ns correctly you should
not get an error.
Laurent Paquereau
Q2S Centre of Excellence, NTNU
Elena Putzolu wrote:
> Hi all,
> I have installed MW-Node patch in ns-2.30(Kubuntu 6.10):
> |patch -p1.
> ./configure
> ||test-all-mwnode| is executable and working but when I execute:
> ns mwnode-ex.tcl
> the result is:
> invalid command name "Channel/Wireless"
> while executing
> "Channel/Wireless create _o14 "
> invoked from within
> "catch "$className create $o $args" msg"
> invoked from within
> "if [catch "$className create $o $args" msg] {
> if [string match "__FAILED_SHADOW_OBJECT_" $msg] {
> delete $o
> return ""
> }
> global errorInfo
> error "class $..."
> (procedure "new" line 3)
> invoked from within
> "new $val_(channel)"
> invoked from within
> "$ns_ wireless-config-routing$val_(routing) \
> -mac$val_(mac) \
> -phy..."
> (file "mwnode-ex.tcl" line 86)
> Which thing does not go?
>
> thanks!
>
> Any suggestion will be appreciated!
> Elena
>
>
>
>
> Chiacchiera con i tuoi amici in tempo reale!
> http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
Re: [ns] Multi-interface support howto
Nguyen, I try in this post to sum up and explicit the main differences between the approach proposed by R.Aguero et al. in their how-to and ours with the MW-Node. I hope it helps you choosing what better fits your needs. 1) R.Aguero et al., "Adding Multiple Interface Support in NS-2" (document, http://personales.unican.es/aguerocr) This document describes changes to enable support of multiple interfaces. By to support multiple interfaces they mean to allow to have more than one wireless stack below a single routing agent on a MobileNode. All the wireless stacks are identical (same Mac/Phy). The routing agent code has to be modified to handle more than one wireless stack. This applies only to AODV-like routing agents, that is routing agents using the standard MobileNode, not the SRNode (DSR) or the AODVUUNode (AODV-UU) for example. This functionality is basically what is provided by Hyacinth (http://www.ecsl.cs.sunysb.edu/multichannel/), some flexibility added. To this respect their contribution is to me very similar to the resources available at http://www.cse.msu.edu/~wangbo1/ns2/nshowto8.html 2) Module-based Wireless Node (MW-Node patch + documentation, http://www.q2s.ntnu.no/~paquerea/ns.html) In the following, I focus on the main features of the MW-Node. For implementation details and design choices please refer to the documentation. A MW-Node is a standard Node (not a MobileNode) with capabilities - wireless, mobility, (energy support, not functional yet) - added by means of modules. The purpose of this new design of wireless and mobile networking support in ns2 is twofold: - to support new features such as multiple channels/multiple interfaces, and - to provide a common basis for implementation of any wireless routing protocol instead of having each routing protocol as a particular case (not to say a particular node object) as it is with the MobileNode. We distinguish between: - multiple channels: one single routing object handling several wireless interfaces possibly on different channels, and - multiple interfaces: several interfaces, possibly of different types (e.g different Mac/Phy), with one routing object handling one interface. Following these definitions, R.Aguero et al. how-to discusses multiple channels support only, not multiple interfaces support. The MW-Node supports both. Note that routing agents cannot be used directly with the MW-Node, even in the case of a node with a single interface, and need to be converted. Some guidelines are provided in the documentation. Also, the layout of the MW-Node differs from the layout of a standard MobileNode and therefore from the layout proposed by R.Aguero et al. In the MW-Node, the routing object lies before the address classifier. This is to enforce that data packets pass through the routing object. This is not the case with a standard MobileNode at the destination or at a portal (wired-wireless) node. Finally, a new network interface object is provided and enables: - per interface operation control (e.g. bring up/down one of two interfaces only) - better wired/wireless integration. Regards, Laurent Paquereau Q2S Centre of Excellence, NTNU Nguyen Lan wrote: Hello, I read your post on ns2 mailing list and I have a question what are the differences between your approach and Ramon's approach. Can you give me a suggestion in the case that I like to make a simulation with multi-interface in ns2: which approach is better or easier to implement. Cheers, Nguyen Laurent Paquereau wrote: Ramón, I have been reading your how-to and as your statements and concerns are quite similar to a subset of those we presented last year in [1], you might find interesting reading this paper. [1] Laurent Paquereau and Bjarne E. Helvik, "A Module-based Wireless Node for ns-2", in Proceedings of the first Workshop on NS2: the IP network simulator (WNS2), Pisa, Italy, 2006. A Module-based Wireless Node (MW-Node) is a Node with wireless and mobile capabilities added by means of modules. It is not a new node object derived from Node. Rather it is a new layout of mostly existing components. The aim is to provide a flexible support for wireless and mobile networking and in particular: * support for multiple interfaces/multiple channels, and * a common basis for the implementation of wireless routing protocols. The code is distributed as a patch for ns-2.30 and is now available online with the documentation at: http://www.q2s.ntnu.no/~paquerea/ns.html Feedback and comments are much appreciated. Best regards, Laurent Paquereau Q2S Centre of Excellence, NTNU Ramon Aguero wrote: > Dear all, > > We have seen a lot of requests about the possibility to extend the NS-2 > framework to support multiple interfaces. Although there is some > information available, according to the mes
[ns] Multi-interface support howto
Ramón, I have been reading your how-to and as your statements and concerns are quite similar to a subset of those we presented last year in [1], you might find interesting reading this paper. [1] Laurent Paquereau and Bjarne E. Helvik, "A Module-based Wireless Node for ns-2", in Proceedings of the first Workshop on NS2: the IP network simulator (WNS2), Pisa, Italy, 2006. A Module-based Wireless Node (MW-Node) is a Node with wireless and mobile capabilities added by means of modules. It is not a new node object derived from Node. Rather it is a new layout of mostly existing components. The aim is to provide a flexible support for wireless and mobile networking and in particular: * support for multiple interfaces/multiple channels, and * a common basis for the implementation of wireless routing protocols. The code is distributed as a patch for ns-2.30 and is now available online with the documentation at: http://www.q2s.ntnu.no/~paquerea/ns.html Feedback and comments are much appreciated. Best regards, Laurent Paquereau Q2S Centre of Excellence, NTNU Ramon Aguero wrote: > Dear all, > > We have seen a lot of requests about the possibility to extend the NS-2 > framework to support multiple interfaces. Although there is some > information available, according to the messages that have been sent to > this list, it seems that a more thorough description may be required. > > In this sense, after performing an analysis about existing activities in > this topic, we have created a document that tries to summarize which are > the required changes to be performed within the different pieces of the > simulator (tcl, c++) as well as how routing protocols can be adapted to > make use of the new feature. The howto is entitled "Adding Multiple > Interface Support in NS-2" and it has been written by my colleague Jesús > Pérez and myself. > > I’ve uploaded the document, which can be retrieved from the following url: > <http://personales.unican.es/aguerocr>http://personales.unican.es/aguerocr > > We will be happy to receive any feedback, comments, so as to improve the > howto, since we would like to have it like a living document, adding new > features as they are available. > > Best regards, > Ramón > > > Ramón Agüero Calvo > Dept. of Communications Engineering > Network Planning & Mobile Communications > Laboratory > University of Cantabria > Avda Castros s/n > 39005 - Santander > SPAIN > ramon at tlmat.unican.es > Tel: +34 942 201 392 (Ext 14) > Fax: +34 942 201 488 >
