I am not sure if you are talking about this problem on routing agent...If yes, it is normal since if you checked the structurural diagram of a mobile node in NS2, you can find out that once the packet reaches the destination, the address classifier and port classifier will forward it in different way and the recv() in routing agent does not get invoked at all...The solution also lies in that structural diagram!!!Think about the condition on which address classifier and port classfier will make different selection!!
Hailun Tan > > Hi There, > Thank you again for the reply. This is not my work, I am trying to use > something from NRL for my WSN work. Basically they have multiple > interfaces to a node. One channel carries just sensing info and another > channel is used for routing to sink. They want the sensing info to come to > the agent, so that it can send info about it to the sink on the other > channel. That is why they have the up-target statement in the tcl code. By > doing this, I was hoping the recv will come to the agent and it can handle > it, but it does not. So I am not sure if the problem is in the interface > implementation or somewhere else. Please share your thoughts. > Regards, > Sita > > >> Hi again, >> >> Yes I understand a little more of what you are trying to accomplish, but >> i >> still have some questions; Are you modifying an existing routing >> protocol >> in ns2? Do packets get forwarded correctly from source to destination >> according to your Mac level trace? If the packets don't get forwarded >> there is as you say something wrong with the link layer's connection to >> the network layer (Your Router-module). When I designed my routing >> protocol I started out with AODV and modified it. Also there are some >> pictures of the architecture of the ns2 layers on the Internet that may >> help you. And finally, you say that you changed some thing in the Link >> layer's up target so your routing module will be the receiver of >> packets, >> I'm not sure if you need to do that, if I remember correctly a >> classifier >> gets the packet from the link layer and the classifier decides if the >> packet shall be sent to the routing module for processing (forwarding) >> or >> if the packet shall be sent to agent level (when the pac >> ket have reached it's destination). >> >> Regards Micke >> >> ----- Originalmeddelande ----- >> Från: "Sita S. Krishnakumar" <[EMAIL PROTECTED]> >> Datum: Tisdag, Januari 24, 2006 16:58 >> Ämne: Re: [ns] Agent::recv method not reached >> >>> Mikael, >>> Thanks for your reply. I have more information that may shed more >>> light on >>> the problem. >>> I basically have a new agent designed. In my code, I specify that >>> the link >>> layer's 'up-target' is my agent node so that it can come to my >>> recv() for >>> processing. But looks like that is not working fine. >>> The MAC layer receives the packet but the agent does not. That is >>> why I >>> see it in the MAC trace but not in the agent trace. Even if it >>> does not >>> come to my recv(), it should go to the agent's recv() - but it >>> does not >>> go there either. So I am not sure where it goes altogether. Also I >>> am not >>> sure what the 'add-ll' does when an agent is created. I am trying >>> to add >>> someone else's work. I am not sure why they didn't have an add-ll >>> statement. >>> This is work from NRL and they say it works in 2.27, I am trying >>> to get it >>> to work in 2.29 >>> Thanks, >>> Sita >>> >>> >>> > Hi, >>> > >>> > I had a similar problem, but I?m not sure if I understand >>> exactly what you >>> > mean. >>> > If you are sending one packet from "source" to "destination" >>> over some >>> > number of intermediate nodes, you will only see the packet at >>> agent level, >>> > if you have that trace level turned on in ns2 and you will only >>> see it at >>> > the source and destination node. If you want to do something >>> with your >>> > routing protocol when a data packet has been received at the >>> destination> you have to understand that ns2's layers don't >>> exactly work as the OSI >>> > reference model. When a data packet reaches it's destination a >>> classifier> sends it to the agent layer, so you will never see >>> this packet at the >>> > router layer(Network layer). If I remember correctly this has >>> some thing >>> > to do with the mobile node class. I know for a fact that the AODVUU >>> > implementation uses a newer class where packets are received and >>> sent> bottom up through all layers. So you could use this class or >>> use a >>> > function in agent::recev and call a function in your class but >>> to do this >>> > you have to get hold of that object created by ns2 if you >>> > create a new one and do the call you will not be able to get >>> access to >>> > memory allocations done by your class. For more info on how to >>> this Pedro >>> > Vale Estrela posted some code that I used on this forum some >>> month a go. >>> > Hope this can help you in some way. >>> > >>> > Best regards, Micke J >>> > ----- Originalmeddelande ----- >>> > Från: "Sita S. Krishnakumar" <[EMAIL PROTECTED]> >>> > Datum: Mondag, Januari 23, 2006 15:11 >>> > Ämne: [ns] Agent::recv method not reached >>> > >>> >> >>> >> Hello, >>> >> I am trying to add a new routing protocol to ns-2. There are >>> >> packets being >>> >> generated and received by the nodes (i see it in the MAC trace), >>> >> but it >>> >> never reaches my recv() method. On stepping through, I saw that the >>> >> Agent::recv() is not reached and hence it is not getting forwarded >>> >> to my >>> >> code for processing (no agent traces get printed out in the >>> trace file >>> >> about packets being received) . Any ideas on why this is happening? >>> >> Thanks for your help. >>> >> Regards, >>> >> Sita >>> >> >>> >> >>> > >>> > >>> >>> >>> >> >> > > -------------------------------------------------------------------------- This email and any attachments may be confidential. They may contain legally privileged information or copyright material. You should not read, copy, use or disclose them without authorisation. If you are not an intended recipient, please contact us at once by return email and then delete both messages. We do not accept liability in connection with computer virus, data corruption, delay, interruption, unauthorised access or unauthorised amendment. This notice should not be removed.
