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