[Ns-developers] log time -> log context

[Gustavo Carneiro]

On 23/05/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
> On Wed, 2008-05-21 at 19:35 +0100, Gustavo Carneiro wrote:
>
> >
> > I don't know what else to explain:
> >
> >   /**
> >    * Set the current node that is being simulated.
> >    * \warning this method has no effect on optimized NS-3 builds, as
> > it is used only for logging.
> >    * \param node   id of the current node, or -1 if none or not known
> >    */
> >   static void SetCurrentNode (int32_t node);
> >
> >
> > It's dead simple.  What might be missing perhaps is some guideline
> > explaining when the user is expected to call it.  Is that what you
> > mean?
>
>
> What is "the current node" ? What is its relationship with the "nodeid
> context" embedded in each event ? How does each event get a "nodeid
> context" ? Where does it get it from ?
>
> There are many types of "current node id". There is the one which is
> used to associate a "current node id" to the event scheduled with
> Simulator::Schedule. There is the one which is coming from the "current
> node id" of the event we are currently executing. There is the "current
> node id" used for logging. Explaining clearly the relationship between
> all these different types of "current node id" makes my brain hurt.


OK.  I am assuming here a model where, if there is an Simulator::Schedule
call at some point, we assume that, by default, the callback will be invoked
in the same node where the schedule was made.  I think this is a reasonable
assumption, considering the majority of NS-3 code.  So:

  1. Simulator  currentNode: the ID of the node we think we are simulating
_right now_;

  2. EventImpl nodeId: the ID of the node that was being simulated when the
event was scheduled.

If, by a rare chance, you schedule a callback that will supposedly represent
a transition to another node, you are supposed to override the default NS-3
behaviour and add a Simulator::SetCurrentNode() call to the start of
scheduled callback function.  But I think this is not going to be common, so
the extra effort will rarely be needed.

If I knew that most Schedule calls were Node transitions, I would design a
different API.  As it is now, the API that makes sense to me is this one.

>         Using raw sockets outside of the context of an Application
> >         Start
> >         function makes little sense and is clearly not the way the
> >         system was
> >         designed to be used: yes, it can be made to work, yes, we have
> >         examples
> >         which do this, yes you like being able to do it but, as
> >         discussed a
> >         while ago in a bug report, _this is not the way the system was
> >         designed
> >         to be used_. If, when you do this, you do not get the best
> >         logging
> >         messages in the world without some extra work, such is life.
> >
> > About the extra work:
> >
> >  1. I am not convinced the extra work will be worth anything.  It
> > doesn't improve readability in my opinion;
>
>
> It does not improve code readability. It makes the conceptual model of
> the API much more clear and defines precisely and uniquely what the
> "current node id" means by uniquely associating a single "current node
> id" to each event.
>
> What you are trying to suggest also goes against the design of the
> current API which is to move _all_ per-event arguments to the Schedule
> calls: we could have done what you suggested for all other arguments:
>
> Simulator::SetNextDelay (Time delay);
> Simulator::SetNextArguments (...);


It's not the same thing.  Simulator::SetCurrentNode does not apply to the
next Schedule call specifically; it applies to all future Schedule calls.

Whether or not the above is better than what we have now is not
> something I will argue about. What I will argue about is consistency of
> the design: we are not using this style of API in this header _now_ so,
> we should not use this style for new API in this header.
>
>
> >  2. Adding extra Schedule calls will increasing the number of events
> > and decrease NS-3 performance.  I want the logging improvements to be
> > as little intrusive as possible, as all logging should be.
>
>
> You are worried about minimizing the number of changes to the codebase.


That is not what I said.  I said:  "adding extra Schedule calls will
increasing the number of events and decrease NS-3 performance".

Minizing the number of source code modifications is a different concern.
Also important, given limited amount of hacking time, of course :P

I am worried about making the API understandable and consistent.


Well, I am proposing the only way that makes sense to me.  If it does not
make sense to you then I have to withdraw.  A pity, but I can understand
that it has to make sense to you... it's life.

Regards.

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert