I'm thinking if this has to do with the modification of the SR header: I added an int variable, named "low_energy_", which represents a flag to tell receiving nodes that the source is finishing its energy, but maybe this increases the size of the header too much, over its limit (which I don't know exactly, is it 8 bytes?). I also didn't modify the method ''int size()", to add the size of the integer variable when it returns... Could this be the reason, and if yes, how can I add an option to the SR header safely?
2009/2/26 Salvo Danilo Giuffrida <giuffsa...@gmail.com>: > Hello, I modified the DSR implementation of NS-2, in such a way that, > when a node reaches an energy level below a certain percentage of its > initial level at the beginning of the simulation (say, 30%), it sends > a broadcast IP packet > > SRPacket p; > p.src = net_id; > p.pkt = allocpkt(); > > hdr_sr *srh = hdr_sr::access(p.pkt); > hdr_ip *iph = hdr_ip::access(p.pkt); > hdr_cmn *cmnh = hdr_cmn::access(p.pkt); > > iph->daddr() = IP_BROADCAST; > cmnh->next_hop() = IP_BROADCAST; > iph->dport() = RT_PORT; > iph->saddr() = > Address::instance().create_ipaddr(net_id.getNSAddr_t(),RT_PORT); > iph->sport() = RT_PORT; > iph->ttl() = 1; > > cmnh->ptype() = PT_DSR; > cmnh->size() = size_ + IP_HDR_LEN; // add in IP header > cmnh->direction() = hdr_cmn::DOWN; > > //srh->init(); > srh->low_energy()=1; > > Scheduler::instance().schedule(ll, p.pkt, 0); > > p.pkt = NULL; > > The 'valid' flag of the Source Route header is not set to 1, because > this is a broadcast, route-less packet. That 'low_energy()' method > sets a flag on the header, which I added to indicate that this is a > "low energy" message to neighbors nodes. > After the packet is received by neighbors, that's what happens in recv(...) > > if (srh->valid() != 1) { > unsigned int dst = cmh->next_hop(); > if (dst == IP_BROADCAST) { > // extensions for mobileIP --Padma, 04/99. > // Brdcast pkt - treat differently > if (p.src == net_id) > // I have originated this pkt > sendOutBCastPkt(packet); > > //Lines added by me > else if (srh->low_energy()) { > ID to_id(iph->saddr(),::IP); > ID from_id(net_id.addr,::IP); > > /* kill any routes we have using this link (this node->sender node of > the broadcast packet) */ > route_cache->noticeDeadLink(from_id, > to_id,Scheduler::instance().clock()); > flow_table.noticeDeadLink(from_id, to_id); > > /* now kill all the other packets in the output queue that would > use the same next hop. */ > > Packet *r, *nr, *queue1 = 0, *queue2 = 0; > // pkts to be recycled > > while((r = ifq->prq_get_nexthop(to_id.getNSAddr_t()))) { > r->next_ = queue1; > queue1 = r; > } > > // the packets are now in the reverse order of how they > // appeared in the IFQ so reverse them again > for(r = queue1; r; r = nr) { > nr = r->next_; > r->next_ = queue2; > queue2 = r; > } > > // now process them in order > for(r = queue2; r; r = nr) { > nr = r->next_; > undeliverablePkt(r, 1); > } > return; > > } else > //hand it over to port-dmux > port_dmux_->recv(packet, (Handler*)0); > ... > > The idea is that receivers of this broadcast "low energy" packet would > clear their route caches from the link X->Y, where X it's net_id > (themselves), and Y is the "low energy" node....Then, if packets with > a route having X->Y among the links are received, to be forwarded to a > certain destination, this neighbors nodes would try to savage the > package, or generate an RERR to the original sender. Hopefully, with > new RREQs, a new route, which would not pass for the low energy node, > would be selected (I made other modifications to make this more > likely). But if this node is the only possible route for a certain > destination, it would be used anyway. > What I see happening is that the broadcast packet is received by > neighbors, the link net_id->Y is cleared (I guess), but new RREQs > can't be generated by the other nodes, because for a while the other > nodes are unable to forward packets, and drop them (IFQ_FULL), > including RREQs packets. So, becuase of these dropping, links between > good nodes (nodes with enough energy, and I'm sure it's not a problem > of the interface queue size, because even with a value of 500 packets, > the problem remains). > I can send the Tcl scenario file, and/or the trace output, if anyone > is interested and willing to help. > Also, is there a way to dump the content of a mobilenode's > routecache?...I looked into the source code, and currently the 'dump' > method is unimplemented, and I didn't find in 'routecache.h' any > mention of the data structure where all routes are memorized... > Thanks a lot >