-----Original Message-----
From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Sake Blok
Sent: den 25 augusti 2009 08:58
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev 29523:/trunk/ /trunk/epan/dissectors/: packet-tcp.c /trunk/epan/:column-utils.c column-utils.h column.c column_info.h prefs.c/trunk/gtk/: new_packet_list.c
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?
The problem as I see it is that the current multitude of fixed colums is slowing things down
And complicating the code even if they arn't used.
Custom colums will only cause a perfoprmance hit for the ones using them. Possibly the custom colums code can be made more efficent later. Ideally we should store the binary data used to build
The columns if the frame data structure saving memmory and making it possible to only generate the
Strings when the rows are vissible.
Regards
Anders
___________________________________________________________________________
Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe