[Anders Broman <a.broman@xxxxxxxxxxxx>]

Ambarisha B skrev 2013-05-01 17:01:

On Thu, Apr 25, 2013 at 7:34 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:

But the dissectors create the tvb from the reassembled data. So, if we
define a new type of tvbuff which has to be used, wouldn't that effect
the dissectors?

It shouldn't: dissectors should be using the TVB-accessor functions so they shouldn't care what kind of TVB they are handed.

Please bear with me, I may be missing something obvious here.

Reassembly code returns a fragment_data to a dissector(say, tcp dissector specifically). The dissector uses fragment_data->data in a call to tvb_new_child_real_data(). fragment_data->data points to a buffer containing the complete reassembled pdu. What will this data member contain incase of a reassembly implementation which uses filebacked tvbuffs?

Cheers

Ambarish

File backed tvbuffs are perhaps not the right name, lets go back and examine the problem we want to solve.
Wireshark uses a lot of memory when a capture file is read as it keeps information about every packet in memory
a large part of that is "reassembly data". If that data could be left in the file(and re read when needed) or stored in a new file less memory would be used. One question is if this is feasible from a performance point of view.

After the first read to build information of the packets, packets are randomly accessed(re-read from file) as needed when displayed to the user.

>What will this data member contain in case of a reassembly implementation which uses file backed tvbuffs?

file pointer(s) and length

It may be problematic to obtain the fragments from the original file in case it is gziped or if the fragments are
parts of decrypted packets so writing to a new file might be the best option.

Regards
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