[ns] generate CMPP traffic
Hello, I have tried to generate CMPP traffic in NS by adding a class CMPP_Traffic analogous to Poisson_Traffic . I have made those additions: 1.~ns/tcl/lib/ns-default.tcl : here i have given default values for all the parameters 2.~ns/tcl/lib/ns-source.tcl : here i have first declare my class as Class Application/Traffic/CMPP 3.~ns/packet.h : here i have made entry for my packet type PT_CMPP in teh enum defined there . i have also made the entry name_[PT_CMPP]=cmpp 4. ~ns/trace.h : here in the func. format() i have made entry for my packet type in the if-condition in line 213. There is no problem when i compile ns with my file included in the Makefile. But when i run a tcl script generating CMPP traffic then it gives the following error : _o84:unable to dispatch method attach-agent while executing $traffic attach-agent $udp0 (file cmpp.tcl line40) --- here cmpp.tcl is the name of my tcl script traffic is the object Application/Traffic/CMPP udp0 is the object Agent/UDP Can anybody suggest me what to do???
[ns] how to implement movement for groups of nodes in ns
- Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.
[ns] Web traffic in wireless environment
Hi all, I want to perform a simulation of a kind of XML RPC traffic. As this traffic is usually carried over HTTP in order to make the first tests I want to use any kind of web traffic envionment. I have tried with webcache over a wireless environment and the packets doesn't go out of the node (they are discarded). Does anybody know what can I use to perform such a simulation of web traffic over wireless? All my nodes are wireless and will act as servers and clients (whenever possible). TA. Jorge
[ns] can't send pkt (unicast/broadcast) - MANET ns2.30
Hello ns-suers, i can't send unicast or broadcast packets, I try several solutions, but no one works! 1- the code for unicast (sendUnicast(destination)) Packet* pkt = allocpkt(); hdr_cmn* hdrcmn = hdr_cmn::access(pkt); hdr_ip* iphdr = hdr_ip::access(pkt); hdr_monitor* hdrret = hdr_monitor::access(pktret); hdrret-ret = 1; hdrcmn-next_hop_ = destination; hdrcmn-prev_hop_ = this-addr(); hdrcmn-direction() = hdr_cmn::DOWN; hdrcmn-ptype() = PT_MONITOR; hdrcmn-addr_type() = NS_AF_INET; //NS_AF_INET; // NS_AF_ILINK; // setting the ip header iphdr-saddr() = this-addr(); iphdr-sport() = 100; // 1-254 iphdr-daddr() = destination; iphdr-dport() = 100; // 1-254 iphdr-ttl() = 32; fprintf(stderr, %d send request to %d \n,this-addr(),destination); // send Scheduler::instance().schedule(ll, pkt, 0.0); 2- for broadcast i use the following code Packet* pkt = allocpkt(); hdr_gc* hdr = hdr_gc::access(pkt); hdr-ret = 0; hdr_cmn* hdrcmn = hdr_cmn::access(pkt); hdr_ip* iphdr = hdr_ip::access(pkt); hdrcmn-next_hop_ = IP_BROADCAST; hdrcmn-prev_hop_ = this-addr(); hdrcmn-direction() = hdr_cmn::DOWN; hdrcmn-ptype() = PT_GC; hdrcmn-addr_type() = NS_AF_INET; //NS_AF_NONE NS_AF_ILINK; // setting the ip header iphdr-saddr() = this-addr(); iphdr-sport() = 101; // 1-254 iphdr-daddr() = IP_BROADCAST; iphdr-dport() = 101; // 1-254 iphdr-ttl() = 1; fprintf(stderr, %d send bcats\n,this-addr()); // send Scheduler::instance().schedule(ll, pkt, 0.0); // _target ! - i use the TclObject::lookup to get the ll. Thanks Regards
Re: [ns] Underwater Channel in basic NS2
Hi Dewald, Dewald Nolte wrote: In ns-miracle the documentation claims that the underwater channel works and that some basic MACs are provided, but in one of the mails in the mailing list I read that some of the routing protocols are not yet supported? Basically the underwater-miracle module provides only Channel, PHY and MAC, and relies on nsmiracle for the rest of the protocol stack. The current release of nsmiracle provides only static routing. The future release will include support for routing protocols such as AODV. However, the release date for this version of nsmiracle cannot be predicted at this moment. Also if I go the basic ns way I have to fix the code myself. It has some errors at the moment. Doesnt seem too difficult to fix though. 1. In the underwater-phy.cc of the unsupported underwater code, lambda is defined as: lambda_ = SPEED_OF_LIGHT / freq_; Considering that its an underwater channel, should it not then be the speed of sound?? I guess this value was not used in practice. What I remember of the ns2 underwater module is that is basically used the underwater-phy as an entry point for some other external code. Most of the code copied from the ns2 wireless-phy is not actually used. However, you need to read the code yourself to really understand it. I guess it could be very difficult to contact the original developers of that module. I want to implement my own MAC for the underwater environment. I am looking to use the RTS, CTS, DATA, ACK handshake to implement MACAW. Some of this is already implemented in the 802.11 MAC. So I will try to port that to MACAW. So basically I want to try and use the framework supplied by the 802.11 code and just change what is necessarry to implement my MAC (MACAW). The problem is I dont have enough experience with ns to write my own MAC from scratch, so im doing it this way. 2. Now would it be easier to go with ns-miracle, or try to integrate the unsupported code for the basic ns and use that to keep the routing modules intact? 3. And lastly, can the 802.11 MAC run on the underwater physical layer as it is? Just for starters, I will try to port it eventually to the MACAW protocol... What I can tell you (just my opinion of course) is that dealing with the ns2 underwater module at the PHY and MAC layer is a real mess. This is the main reason why we wrote the underwater-miracle module almost from scratch. Nicola
