[Ns-developers] ns-3 and future development

[mathieu lacage]

Tom Henderson wrote:

>What is your rationale for abandoning the name "Timer" in favor of "EventCancellable"?  Can't we 
>

The rationale is:
  - my 802.11 code uses MacCancellable for the same thing.
  - Timer feels like a higher-level API (this is totally subjective :)
  - if you look at the code and see an instance of a EventCancellable, 
there is little doubt about what it does. Timer, on the other hand, has 
been abused to mean everything possible under the sun.

>just define Timer as a cancellable Event (your previous message had class Timer : public Event)?  In perusing the ns-2 source, all events are cancellable, but it seems that only timers actually make use of the function.
>
>Also, as far as implementation goes, it seems in ns-2 that cancelling an event requires to go into the scheduler and find it.  I wonder whether it will be more efficient to avoid how ns-2 does it and just flag the event as cancelled, and stay out of traversing the list/heap.  I don't know whether this will significantly increase the average number of events in the scheduler, impacting other operations such as ordered insert.  Has anyone studied this tradeoff?
>  
>

yes, I did back when I wrote the 802.11 code for ns-2 :)
Because it might be of interest to you and others, here is the result of 
a simple test with and without the attached patch against my 802.11 fork 
of ns2 (this is against the code's tip, not the released version):

use scheduler's cancel (use the attached patch):
[mlacage at chronos ns-2]$ time -p ./ns 80211/test-80211.tcl >out
real 85.63
user 84.30
sys 0.67

use event's cancel (the default in my 802.11 code):
[mlacage at chronos ns-2]$ time -p ./ns 80211/test-80211.tcl >out
real 87.79
user 85.61
sys 0.56

What does this tell you ? Nothing really significative.

However, I believe that the API I propose can be implemented either way. 
i.e., the call to Event::cancel can be made to call into the scheduler's 
cancel method if there is one and delete itself. User code is supposed 
to do this either way so such an implementation change should have no 
impact on users:
m_event->cancel ();
m_event = 0;

So, we probably do not need to argue about how to implement it and we 
can revise the implementation later trivially.

>Current ns-2 has resched(delay) and differentiates from IDLE(INITIAL) and PENDING(i.e., RUNNING) states.  
>  
>
Being able to know the difference between INITIAL and RUNNING requires 
the addition of a start method on the Timer class. I have decided 
against this to avoid duplicating functionality already provided by the 
Simulator::insert_* family of methods. I feel that good APIs are 
orthogonal one to each other and do not duplicate functionality.

Knowing the difference between INITIAL and RUNNING will allow you to 
catch cases where you schedule twice the same event instance. This never 
happened to me but it might be worth being caught. I will try to see if 
I can come up with a design which does this and avoids the addition of 
an extra start method.

Mathieu