[Ns-bugs] [Bug 385] Add a generic "sequence number" class

[code@nsnam.ece.gatech.edu]

http://www.nsnam.org/bugzilla/show_bug.cgi?id=385





--- Comment #27 from Craig Dowell <craigdo at gmail.com>  2010-06-20 16:05:12 EDT ---
> It's probably better to just wrap in TracedValue when needed.

I agree with this.  When I say "easily traceable" what I mean is a sequence
number class that works when used standalone in a model, and when I:

  .AddTraceSource ("SequenceNumber",
                   "My sequence number to trace.",
                   MakeTraceSourceAccessor (&MyObject::m_sequence))

  ...

  TracedValue<SequenceNumber> m_sequence;

it gets traced correctly and just works.

It seems to me that at least a couple of people have demonstrated classes that
can work this way, and that's all I really want at the highest level.  Our
protocol implementations should provide the trace hooks for important sequence
numbers.

My other comments derive from the fact that I was appalled when writing a
tracing tutorial how much work would've been required to backfit sequence
number tracing into TCP.  It was a rather large project (still will be to
convert to a new seq type).  I was looking for a way to enable tracing on
something that was not explicitly written to support it, or to enable tracing
without having to construct chains of Ptr<Object> which seems to confuse the
heck out of our novice users.

In any case, I support adding Gustavo's class (without the Object overhead) and
a trace test, and then actually using the class and exporting the trace hooks.

-- 
Configure bugmail: http://www.nsnam.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.