> I am saving information from frame to frame in the conversations. In
> particular, I have a field that says whether or not we have seen the
> response to a request, and if we have, then the subsequent ones must simply
> be continuations.
>
> Unfortunately, if you select a response, then go and select some other
> frame, and then come back and select the original response, you will get
> the wrong result.
>
> Are we not storing the decode trees for each frame?
Nope.
> Do we really only decode them as frames are selected?
Yup.
My original thoughts for handling packet reassembly was to save, with
each frame, the protocol tree for each frame, so that you would only
have to reassemble the frames when making the initial pass through the
file.
However, there was, as I remember, a bug where the protocol trees (which
*weren't* being saved) were not getting freed; fixing that bug
substantially sped up the process of reading in a capture. Part of the
problem is that increasing the size of a process' heap isn't cheap -
on UNIX-flavored systems, there's an "sbrk()" system call that expands
the address space, possibly adding new page table entries, and then
either a zeroing of the page or a zero-fill-on-demand page fault on the
new page followed by a zeroing of the page. In addition, that boosts
the number of pages the process requires, and could increase the amount
of paging the machine does.
In addition, the initial pass through the capture file does a
"summary-only" dissection, with the "tree" argument null; generating the
protocol tree as the file gets read in would slow down the initial pass
even more.
Thus, I'm inclined to avoid storing the protocol trees if at all
possible.
An alternative might be to provide a mechanism by which dissectors can
attach information to a frame if necessary; the information attached to
the frame would probably take less memory than a full protocol tree,
and, in many cases, no information would need to be attached to the
frame.
