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
>
