[Ns-developers] log time -> log context

[Mathieu Lacage]

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.

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. 

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

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

Mathieu