[Ns-developers] log time -> log context

[Gustavo Carneiro]

2008/5/19 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

> On Mon, 2008-05-19 at 17:10 +0100, Gustavo Carneiro wrote:
>
> >         I would have expected that you modify the code of applications
> >         to set
> >         the node id prior to scheduling socket-related events.
> >         Actually, you
> >         might get away with just modifying Application::Start and Stop
> >
> > Sure, that too.
> >
> > But since user code is allowed to use sockets directly, we still need
> > to set node id in socket APIs, not just applications.  Yes, I know you
>
> Yes: I would have expected user code to take care of that but it might
> be a good thing to set the node id from the socket code if it is not set
> already so, +1 to your idea of doing it in the socket.
>
> >  would prefer if applications were the only source of traffic in NS-3
> > programs, but I think we have already agreed to also support user
> > programs using sockets directly as well...
> >
> > There are quite a few more places where the current node id should be
> > set, of course.  This is only a proof-of-concept for now, waiting for
>
> 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.


>
>
> >  a verdict.
>
> Since I suggested that approach to you on irc in the first place to
> solve your logging problem, I would tend to support it but, as you say,
> there is a clear per-event memory cost so, it might make sense to make
> that code be ifdefed (make Simulation::SetNodeId do nothing if it is
> ifdefed out) and enable it only in debug builds for now.


OK.


> 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;

    2) it does not scale (e.g. what if one day we want to support current
NetDevice as context, add more overloaded);

    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 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.

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