On Sun, Aug 23, 2009 at 05:25:38PM +0200, Kovarththanan Rajaratnam wrote:
> Stig Bj�rlykke wrote:
> > On 23. aug.. 2009, at 14.24, krj@xxxxxxxxxxxxx wrote:
> >
> >> Log:
> >> Custom columnfication:
> >>
> >> * Deprecate COL_REL_CONV_TIME (Relative time (conversation)). Use
> >> tcp.time_relative
> >
> > What about conversations other than tcp?
>
> COL_REL_CONV_TIME and COL_DELTA_CONV_TIME are pretty generic but they
> were only used within the TCP dissector, so I didn't think that
> converting them would be controversial. So far I've only converted
> columns that were restricted to one dissector.
When I wrote the "Conversation Timestamps" functionality, I had in mind
to make it open enough for other protocols to also generate conversation
timestamps (I only implemented the tcp version so far). The column would
be a container that just shows the conversation timestamps for the
highest layer. Dropping support for the specific column values will
result in having to add multiple columns, one for each protocol that has
conversation timestamps. However, the same functionality can be achieved
with adding a frame.conv_time.relative and frame.conv_time.delta field
that gets updated by all protocols that support conversation timestamps.
Then that field can be used in a custom column.
Does anyone think this functionality is needed? Or are we analysing one
or two layers of conversations at a time and be fine with having to add
the specific protocol timestamps manually?
One other concern with transforming fixed columns to custom columns,
what is the impact on performance? I can imagine custom columns to be
much slower, so maybe some widely used fixed columns should stay fixed
for performance sake. Did anyone test this?
Cheers,
Sake