[Ns-developers] log time -> log context

[Mathieu Lacage]

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.

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

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

regards,
Mathieu