[Ns-developers] log time -> log context

[Gustavo Carneiro]

On 20/05/2008, Mathieu Lacage <mathieu.lacage at sophia.inria.fr> wrote:
>
> On Mon, 2008-05-19 at 21:13 +0100, Gustavo Carneiro wrote:
>
> >
> >         yes. In the channels, of course.
> >
> > Well, right now it happens in NetDevice receive functions, which is
> > not bad, although not perfect.  Ideally it would be in channel receive
> > functions, of course, if such a thing exists.
>
>
> In the WifiNetDevice, you really want to do it in the PHY/channel.
> receive functions.
>
>
> >
> >         Another issue to consider is that of the API
> >         (Simulator::SetNodeId): I
> >         am not super happy about its semantics which are: "store
> >         something
> >         somewhere until the next Simulator::Schedule event happens at
> >         which
> >         point the node id is read from that magic store and stored in
> >         the event
> >         itself". I have to confess that I would feel somewhat more at
> >         ease with
> >         a new set of overloaded Schedule methods which would take the
> >         extra node
> >         id and which would be used only in the very few places where
> >         they are
> >         needed (mainly application, socket, channels).
> >
> > Yes, I know this is what you suggested on IRC, overloaded Schedule
> > methods.  But:
> >
> >     1) it is tedious to implement, since these methods are replicated
> > for 1-5 arguments and use a lot of template black magic;
>
>
> I know.
>
>
> >
> >     2) it does not scale (e.g. what if one day we want to support
> > current NetDevice as context, add more overloaded);
>
>
> I know that it does not scale but that was a decision a long time ago.
> We felt that the improvement from:
>
> Simulator::Schedule (Seconds (1.0), MakeEvent (&MyFunction));
> to:
> Simulator::Schedule (Seconds (1.0), &MyFunction);
>
> was worth the implementation pain.


I was not involved in those discussions, but the way I see it the change was
to allow arbitrary callback parameters passed from to the code that calls
schedule to the function that receives control from the scheduler.  A rather
substantial change.

What we are talking here is merging two completely orthogonal APIs into a
single one.  A lot of coding for no apparent gain.  Or at least I don't
understand the gain...

Now, if you really care about these other things, please, let's think
> about them _now_ before we go further and let's try to figure out
> whether it makes any sense to try to support further context information
> than the node id.


I am thinking of netdevice number as context.  At least temporarily until
control reaches the IP layer.  But that would be very low on my priority
list.

>     3) most importantly, thinking about it some more I realized most
> > of the time the code that does the schedule does not know, or should
> > not know, the target node.  Instead it is the code receiving the
> > schedule that knows its own node.   Additionally, sometimes context
>
>
> Theoretically, you are right but this muddies even more the semantics of
> SetNodeId: "ignore the current event's node id, set the current context
> to this value, use it for the next Schedule call to store in the event
> its associated context".


OK, I think with an example it is better to understand why this makes sense:


void
CsmaChannel::PropagationCompleteEvent()
{
  NS_LOG_FUNCTION (this << m_currentPkt);
  NS_LOG_INFO ("UID is " << m_currentPkt->GetUid () << ")");

  NS_ASSERT(m_state == PROPAGATING);

  NS_LOG_LOGIC ("Receive");

  std::vector<CsmaDeviceRec>::iterator it;
  for (it = m_deviceList.begin(); it < m_deviceList.end(); it++)
    {
      if (it->IsActive())
      {
        it->devicePtr->Receive (m_currentPkt->Copy ());
      }
    }
  m_state = IDLE;
}

It's easy to see that, in this case, changing node id context is done via a
simple method call, not a schedule.  To support node id contexts here, I
would need to change current node right before each it->devicePtr->Receive
() call, and put it back in the end to the original value.

Therefore, SetNodeId() works and is the simplest solution.  Putting a nodeId
in Schedule calls would not be flexible enough, and would not be in any way
simpler.  Two API calls instead of one is often a simpler solution.


>  transitions should happen before any schedule callback, as seen in
> > the socket example, where a stack of functions calls are made before
> > any schedule is done, and we want the logging messages to reflect the
> > actual current node during all those calls.
>
>
> If you do the nodeid setting in the first schedule done at the
> application layer, you will not have this problem in this case.


But it would not fix the direct socket  issue.  A lot happens in socket code
before the first schedule is even invoked.  We want everything to be
correctly associated with the current node.

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