[Ns-bugs] [Bug 631] RealtimeSimulatorImpl not compatible with python bindings

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=631


Craig Dowell <craigdo at ee.washington.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |craigdo at ee.washington.edu




--- Comment #11 from Craig Dowell <craigdo at ee.washington.edu>  2009-07-13 15:02:17 EDT ---
I agree with Gustavo in that there a simple case that we should make very
simple to use.  Using the default simulator implementation and calling in to
run one event seems to be a nice approach -- it seems to be to be such a nice
mechanism for GUIs that I think we should resist taking it away.  I agree with
Mathieu wholeheartedly in that RunOneEvent just isn't reasonable for anthing
but the simplest case, though.  There are alternatives like scheduling periodic
callbacks, but then you immediately run into complication either at the low
level since you lose control for arbitrary lengths of time, or at hgih level
since the callback comes back in the context of the calling thread. 

I hate to bring it up (okay, I don't), but I think we are really swerving into
the question of how to deal with capabilities.  For the NetDevice we have
degenerated into a bunch of pure virtual methods asking capabilities questions
like IsBroadcast, IsMulticast, IsBridge, IsPointToPoint (that are sometimes
mixed in with state questions IsLinkUp).  Using this approach you would do
something like

  if (nd->IsBlah ())
    {
      nd->DoSomething ();
    }

I hope we don't start adding similar things to Simulator.  I originally wanted
to give QueryObject powers to the simulator to resolve some of this kind of
issue.  A similar thing came up in the context of getting the actual underlying
real time clock and scheduling real time events.  A compromise was reached and
we gave clients the ability to get and cast a pointer to the underlying
implementation.  You can see this in the (not very robust code from) emu
device,

  DynamicCast<RealtimeSimulatorImpl> (
    Simulator::GetImplementation ())->ScheduleRealtimeNow (
      MakeEvent (&EmuNetDevice::ForwardUp, this, buf, len));

One way to deal with this problem is to QueryObject for a single event
"Interface" and use it if you need it.  The default simulator implementation
could aggregate an interface for single stepping the simulation, while the more
complex implementations could decide based on their own issues whether or not
to provide it.  

  pi = nd->QueryObject<SimulatorSingleStepper> ();

  ...

  if (pi)
    {
      pi->RunOneEvent ();
    }

If we do it this way, we should think about making all of our similar
capabilities checks work the same way (i.e. net device)

Another way to deal with this issue is through some form of traits, templated
or inherited.  Perhaps

  if (ns3::simulator_capabilities<RealTimeSimulatorTraits>::CanRunOneEvent ())
    {
       Simulator::RunOneEvent ();
    }

This requires the client to know the concrete type of the class, and keep the
trait queries coherent with the current implementation.

If we inherit capabilities classes (ADT) then we end up with something like

  if (ns3::Simulator::Capabilities::CanRunOneEvent ())
    {
       Simulator::RunOneEvent ();
    }

But then you have to deal with plumbing the capabilities from the Simulator
wrapper down into the implementation, which I hate.  We just got done pulling a
lot of that nonsense out of Ipv4, so it should really be more like the emu
example above

  pi = Simulator::GetImplementation ();
  if (pi->Capabilities::CanRunOneEvent ())
    {
       Simulator::RunOneEvent ();
    }

But if you think about it, this is quite similar to a QI but lacks the
clean-ness of the interface separation.

Anyway, we are at the point again, where contemplating this stuff always seems
like too much work to get feature X alone working, but if we don't deal with
it, we end up with loads of silly and annoying IsBlah () and IsYadda ()
functions that need to be plumbed and implemented constantly.

It might not surprise most of you, but I like the QueryObject option.


-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.