Re: [ns] nam trace of a particular flow - is it possible?

[Tarik Alj <aljtarik@cholla.inrs-telecom.uquebec.ca>]

>I think you could pipe into a filter first that examines the nam stuff
>line by line and filters on a colour set by flowid. Not quite as easy
>as doing same for .tr stuff...

you can do that with (n)(g)awk, it just consummes lots of memory and has a 
tendancy to slow down the simulations. But yes I strongly support the idea 
below. Especially the fact that you should be able to chose wether you want to 
enable tracing or not on a per agent basis.

It would also be nice to enable tracing on a per node basis, so as to choose 
"where" to record events in a given topology.

>
>But really, what I think is needed in ns (a la that debug_
>functionality idea allman had) is a global don't-trace or trace flag
>(bound var) that is inherited by all created objects, and which can be
>set explicitly for each object to tell trace-all and namtrace-all
>what to record. So that you can do e.g.
>
>   set ns [new Simulator]
>   $ns set trace_ 0 ;# disable all tracing - trace-alls record nothing
>   set node0 [$ns node]
>   $node0 set trace_ 1 ;# enable tracing just for this node
>
>   set agent0 [new Agent/UDP]
>   $agent0 set trace_ 1 ;# enable tracing for this agent.
>
>and have trace-all and namtrace-all pick up on that. Far easier than
>postfiltering.
>
>packets created by an agent (which has the trace_ bound
>variable) would need to have a new header field saying trace me/don't
>trace me.
>
>$ns set trace_ returns 1 if not set, so all events are recorded (as
>is the present case).
>
>Since events involve more than one object, and the objects can have
>different trace rules, doing the intuitive thing gets a little hard.
>
>Suggestion: 
>if the global [$ns trace_] returns 0, then a packet interacting with a
>node/link where the objects have different trace values is recorded.
>
>if the global [$ns trace_] returns 1, then a packet interacting with a
>node/link where the objects have different trace values is not
>recorded.
>
>..and you could schedule flipping the trace_:
>
>$ns at 50.0 "$agent0 set trace_ 0" ;# no longer interested in that 
>$ns at 50.0 "$agent1 set trace_ 1" ;# what's that doing?
>
>
>> I guess in principle, it's not difficult - packets could be checked for a
>> particular fid, for example, and if it has one of a set of specified fids
>> then all events pertaining to that packet could be logged.
>

could we please avoid using fid_, it's used by too many different things within 
ns (from webcache to SimpleIntServ).
 



Tarik