[Ns-bugs] [Bug 893] Lazy CourseChange notification for WaypointMobilityModel
code at nsnam.ece.gatech.edu
Fri Aug 6 16:01:28 PDT 2010
--- Comment #5 from Tom Henderson <tomh at tomh.org> 2010-08-06 19:01:28 EDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > if m_current is set to m_next, and the next time Update() is called (at
> > m_next.time), now will be equal to m_current.time (which was set to m_next.time
> > previously), and the method will return without the notification.
> Let me see if I can clarify what it's doing-
> If m_current gets set to m_next, there's two possibilities for the value of
> 'now' depending on when Update() was last called. If Update hasn't been called
> in a while, there's a possibility that the loop will iterate again and advance
> to an even newer waypoint, until it reaches the point where now >= m_next.time.
> In the case of non-lazy updates, we don't have to worry about this loop ever
> executing more than once. At this point, 'newWaypoint' is true, so
> NotifyCourseChange is called at the end of Update(). By scheduling Update() to
> be called at exactly the time of each waypoint, we force m_current to roll over
> to m_next and call NotifyCourseChange right away.
> Your concern does apply to the first waypoint, but I'm not certain of what the
> notification behavior should be there. If, at t = 0, we create the first
> waypoint at t = 10, which is when the node starts moving, then shouldn't the
> first notification be when the course changes at the second waypoint? If not,
> it'd be easy enough to schedule a notification at the time of the first
> waypoint as a special case.
I would be OK with the first notification being at the second notification, as
you stated above.
> > But, I think a test case will settle the issue, so if you think it will work OK
> > and have a test for it, I'm fine with your suggestion.
> I can write up a test case but I probably won't be able to present any
> verification before the 3.9 deadline (assuming end of day today).
I can give you relief on that deadline; this seems close to getting done.
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the Ns-bugs