Hi Alec, Thanks for your suggestion. I added debug statements in getParent(), selectRoute(), chooseParent(), TimerTask() to see how the nodes get their parent address.
First, Surge calls the getParent() function where the nodes set the parent address as 0xffff. Then Surge does a (call Send.send(&gMsgBuffer,sizeof(SurgeMsg))) != SUCCESS), where the selectRoute() function is called. Now, the "if (gpCurrentParent == NULL)" condition is never satisfied because the getParent() function has already changed the gpCurrentParent value to 0xffff for all the nodes. So, I think it will not help us by hardwiring the routes at selectRoute(). Also, in MultiHopLEPSM, TimerTask() is called whenever the timer fires which in turn calls chooseParent(). I think gpCurrentParent is updated here too. Why do we have this TimerTask()? Is this for a periodic update for finding the parent depending on the hop, receiveEst, etc. values. I think we need to hardwire the routes at getParent() itself. If chooseParent() is only used for a periodic update, then we can comment chooseParent() as well as TimerTask(). Can you please post your suggestions. Thanks a lot for your help and time. Regards, Yogesh. --- [EMAIL PROTECTED] wrote: > > Hi, > > If the parent is in the neighbor table, meaning > you can assign a table entry pointer to gpCurrentParent, you can > hardwire the parent > in chooseParent(). > > If you don't care about the neighbor table, > simply hardwire the route. Do it at RouteSelect.selectRoute. This is > probably the easiest place to modify. > > Something like: > > pMHMsg->sourceaddr = TOS_LOCAL_ADDRESS; > pMHMsg->hopcount=gbCurrentHopCount;//hardwire > Msg->addr = gpCurrentParent->id; //hardwire > > return SUCCESS; > > should do. Hope this helps. > > alec > Content-Type: multipart/alternative; > boundary="0-2031195102-1104372015=:21939" > > > --0-2031195102-1104372015=:21939 > Content-Type: text/plain; charset=us-ascii > > Hi Philip, > > Thanks for your help. I looked at app.c and saw that the Surge > application is using the MultiHopEngineM.nc and MultiHopLEPSM.nc > modules. I have made the following observation. Please correct me if I > am wrong. > > MultiHopEngineM has all the sending, forwarding and receiving functions > & MultiHopLEPSM has all the neighbor table update & parent selection > functions. Surge calls the RouteControl.getParent() function which is > defined in MultiHopEngineM which in turn calls the > RouteSelectCntl.getParent() function in MultiHopLEPSM, where we get the > parent addr from gpCurrentParent. > > My task is to implement static routes in Surge application. So, I am > ONLY interested in the parent address. I have thought of 2 ways of > implementing this: > > Have a case statement which sets the parent address for all the nodes > in MultiHopEngineM, and then return the parent address in > MultiHopEngineM itself. We can then "unwire" the MultiHopLEPSM module > because we are not interested in having a nighbor table. > > Have a a new struct in MultiHopLEPSM which only declares the parent > and point gpCurrentParent to this new struct. We then comment out > everything except the StdControl functions in MultiHopLEPSM. > > Can you please suggest which one of the two is a better way to implement > static routes. Thanks a lot for your time and help. > > Regards, > Yogesh. > > > > Philip Levis <[EMAIL PROTECTED]> wrote: > On Dec 29, 2004, at 11:35 AM, Yogesh Iyer wrote: > > > Hi, > > > > I am trying to understand the multihop routing implemented by Surge. > > Surge uses the MultiHopRoute.nc for routing. > > > > Now, In the implementation section of the MultiHopRoute.nc file, there > > > are preprocessor directives defined on the OLD_ROUTING identifier. I > > wanted to know whether the Surge application executes the > > Old_routing (the MultiHopRouteM module) or the else part (the > > MultiHopLEPSM module). > > > > Can someone please help me understand how to figure that out? > > > > Thanks, > > Yogesh. > > > > Three ways: > > 1) Make docs and look at the component graph > 2) take a look at build/*/app.c (the generated C file) and see which is > there > 3) Run it in TOSSIM and use gdb > > Phil > > --------------- > > "We shall not cease from exploration > And the end of all our exploring > Will be to arrive where we started > And know the place for the first time." > > - T. S. Eliot, 'Little Gidding' > > > > --------------------------------- > Do you Yahoo!? > Yahoo! Mail - now with 250MB free storage. Learn more. > --0-2031195102-1104372015=:21939 > Content-Type: text/html; charset=us-ascii > > <DIV>Hi Philip,</DIV> > <DIV> </DIV> > <DIV>Thanks for your help. I looked at app.c and saw that the Surge > application is using the MultiHopEngineM.nc and MultiHopLEPSM.nc > modules. I have made the following observation. Please correct me > if I am wrong.</DIV> > <DIV> </DIV> > <DIV>MultiHopEngineM has all the sending, forwarding and receiving > functions & MultiHopLEPSM has all the neighbor table update > & parent selection functions. Surge calls the > RouteControl.getParent() function which is defined in > MultiHopEngineM which in turn calls the RouteSelectCntl.getParent() > function in MultiHopLEPSM, where we get the parent addr from > gpCurrentParent.</DIV> > <DIV> </DIV> > <DIV>My task is to implement static routes in Surge application. > So, I am ONLY interested in the parent address. I have thought of 2 > ways of implementing this:</DIV> > <OL> > <LI>Have a case statement which sets the parent address for all the > nodes in MultiHopEngineM, and then return the parent address in > MultiHopEngineM itself. We can then "unwire" the MultiHopLEPSM module > because we are not interested in having a nighbor table.<BR></LI> > <LI>Have a a new struct in MultiHopLEPSM which only declares the parent > and point gpCurrentParent to this new struct. We then comment out > everything except the StdControl functions in MultiHopLEPSM.</LI></OL> > <P>Can you please suggest which one of the two is a better way to > implement static routes. Thanks a lot for your time and help.</P> > <P>Regards,<BR>Yogesh.</P> > <DIV> </DIV> > <DIV><BR><BR><B><I>Philip Levis <[EMAIL PROTECTED]></I></B> > wrote:</DIV> > <BLOCKQUOTE class=replbq style="PADDING-LEFT: 5px; MARGIN-LEFT: 5px; > BORDER-LEFT: #1010ff 2px solid">On Dec 29, 2004, at 11:35 AM, Yogesh > Iyer wrote:<BR><BR>> Hi,<BR>> <BR>> I am trying to > understand the multihop routing implemented by Surge. <BR>> Surge > uses the MultiHopRoute.nc for routing.<BR>> <BR>> Now, > In the implementation section of the MultiHopRoute.nc file, there > <BR>> are preprocessor directives defined on the OLD_ROUTING > identifier. I <BR>> wanted to know whether the Surge application > executes the <BR>> Old_routing (the MultiHopRouteM module) or > the else part (the <BR>> MultiHopLEPSM module).<BR>> > <BR>> Can someone please help me understand how to figure > that out?<BR>> <BR>> Thanks,<BR>> Yogesh.<BR>> > <BR><BR>Three ways:<BR><BR>1) Make docs and look at the component > graph<BR>2) take a look at build/*/app.c (the generated C file) and see > which is <BR>there<BR>3) Run it in T! > OSSIM and > use gdb<BR><BR>Phil<BR><BR>---------------<BR><BR>"We shall not cease > from exploration<BR>And the end of all our exploring<BR>Will be to > arrive where we started<BR>And know the place for the first > time."<BR><BR>- T. S. Eliot, 'Little Gidding'<BR><BR></BLOCKQUOTE><p> > <hr size=1>Do you Yahoo!?<br> > Yahoo! Mail - now with 250MB free storage. <a > href="http://us.rd.yahoo.com/evt=29914/*http://info.mail.yahoo.com/mail_250";>Learn > more.</a> > --0-2031195102-1104372015=:21939-- > > _______________________________________________ > Tinyos-users mailing list > [email protected] > http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users > __________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com _______________________________________________ Tinyos-users mailing list [email protected] http://mail.Millennium.Berkeley.EDU/mailman/listinfo/tinyos-users
