Two things: The window that I mentioned, showing progress of processed packet data, that window appears twice. Is this a redundancy that could be eliminated?
I tried the first idea I mentioned in my previous email, and it eliminated half of my problems. Previously there were a few major hangups I was experiencing: :- First, clicking the initial packet caused the 'Processing packet data' window to appear twice. :- Opening my dissector's tree caused the same thing to happen :- Clicking line items in my tree, or opening subtrees would cause the 'processing' window to appear twice, then a very long delay I normally don't wait for (waited 10 min once before giving up). I've managed to eliminate the last two by trying the 1st idea I mentioned previously. I don't know that I like the fix, but it eliminates the worst of my problems. However, as I mentioned, any ideas you may have would be appreciated. -Brian Brian Vandenberg wrote: > I'm writing a dissector for a protocol that is transmitted through > http packets. It compresses the original data, then sends it via > http. After decompressing it, I'm creating a new datasource: > > new_tvb = tvb_new_real_data (raw_data, raw_data_length, raw_data_length); > tvb_set_free_cb (new_tvb, g_free); > tvb_set_child_real_data_tvbuff (tvb, new_tvb); > add_new_data_source (pinfo, new_tvb, "Raw data"); > > ... then doing dissection on new_data. Everything seemed fine until > I started dissecting packets with large amounts of raw data (100k+). > The more raw data I have, the worse performance gets (go figure). > When there's a large enough amount of data to dissect I get a window > that says "Processing packet details", with status information such as > the number of bytes processed, etc. > > I've tried breaking during this process to see where in the code it's > at, but visual studio never asks for a source file; it displays a > disassembly window and it's not at all obvious to me where it's at in > processing. > > So, I guess what I'm wondering is, is this expected behavior when > trying to crunch this much data? I'm only adding a few things to the > tree right now, namely an FT_UINT8 (with an associated value_string > array), an FT_UINT16 (displayed using BASE_DEC_HEX), and FT_BYTES; the > latter may require a large number of bytes to be selected (this > particular payload type could have 500k or more that gets highlighted > in the tree view). > > If this is expected behavior, do you have any suggested workarounds? > A few things I've thought of: > > :- For each payload in a given packet, generate a new data source (I'm > not sure I like this idea; there could be 20-50 payloads in a given > packet) > :- For each payload, create a new line item in the packet list (I'm > not sure how to go about this, but it's probably not hard and this > seems like a decent way to approach the problem, but my qualm with it > is that it seperates payloads from eachother) > > Any ideas/suggestions you may have would be appreciated. > > -Brian > _______________________________________________ Wireshark-dev mailing list [email protected] http://www.wireshark.org/mailman/listinfo/wireshark-dev
