Ambarisha B skrev 2013-05-01 17:01:
On Thu, Apr 25, 2013 at 7:34 PM, Jeff Morriss
<jeff.morriss...@gmail.com <mailto:jeff.morriss...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
