Wireshark-dev: [Wireshark-dev] Problems dissecting large amounts of data
From: Brian Vandenberg <phantal@xxxxxxxxx>
Date: Tue, 26 Sep 2006 11:02:53 -0600
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