Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] Reduce memory consumption by re-reading data from file for r

From: Anders Broman <a.broman@xxxxxxxxx>
Date: Mon, 01 Nov 2010 21:26:36 +0100
Jeff Morriss skrev 2010-11-01 20:21:
Anders Broman wrote:
- Store the file pointer in the topmost TVBUFF_REAL_DATA changing the
type to something like
   TVBUFF_REAL_DATA_FROM_FILE to differentiating it from tvb:s not
constructed from file data.

- When making sub tvb they'd have the type TVBUFF_SUBSET_FROM_FILE
I think the top-level would also need to store the offset into the file.
   SUBSET and COMPOSITE TVBs would not have to change at all, except if
maybe to have a bit that says their backing is persistent.
Sorry, I didn't mean the file handle but rather the file offset. The SUBSET tvbs would then need
their own file offset. I haven't looked at the COMPOSITE type - a problem?
- The reassembly routines should then be changed to not store the
fragments but rather the file offset
   and length when all fragments are available and needs to be presented
that data is read from file and
   stuffed into a "reassembled data tvb".  Possibly data should be kept
around until the final packet in a reassembly sequence on the first pass
for speed.
I had been thinking it would build up composite TVBs using the passed-in
TVBs.  Since the TVBs would now be "persistent" this would be okay (we
recently discussed composite TVBs and why they're not used much
now--basically it's because the underlying TVBs aren't persistent).

Did I miss something? Feasible?
I don't think so and I think yes.

(I came back from Sharkfest thinking I'd build a prototype of this, but
you can see how much work I've done on it! :-()
Should we go ahead and check in changes toward this goal in trunk or open up a test-branch or just privately try to build a prototype, collaboration might be quicker. The needed changes to tvbuff.[ch]
shouldn't be that extensive - I hope.
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