Re: Filebacked-tvbuffs : GSoC'13

[Anders Broman <a.broman () bredband net>]

Ambarisha B skrev 2013-05-01 17:01:
> On Thu, Apr 25, 2013 at 7:34 PM, Jeff Morriss 
> <jeff.morriss.ws () gmail com <mailto:jeff.morriss.ws () gmail com>> 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 () wireshark org>
> Archives:    http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
>               mailto:wireshark-dev-request () wireshark org?subject=unsubscribe

___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe