Ambarisha B skrev 2013-04-19 23:01:
Hi,
On Thu, Apr 18, 2013 at 11:31 PM, Ambarisha B <b.ambari...@gmail.com
<mailto:b.ambari...@gmail.com>> wrote:
I'll also see if I can get a profile from massif as Evan suggested.
I tried out massif on wireshark today. I just profiled on a
web-browsing session capture file of 12Mb. I am not sure if that is
too less to profile on.
Wireshark's memory usage was about 60mb. When browsing the packets,
~35% of the memory was g_malloc'ed. Infact, the reassembled data is
also g_malloc'ed in fragment_add_work(). Looking more closely, about
20% of this(20% of total) is because of reassembly (g_malloc() from
fragment_add_work()). Ofcourse, this is with such a small capture. On
large captures, the percentage would probably shoot up.
I have attached the massif output and ms_print output (1mB I'm not
sure if that's ok). Just search for "g_malloc " or dissect_tcp_payload
in ms_print, to find the interesting part. Also some of the function
names are missing. But the two above dissect_tcp_payload are
definitely desegment_tcp() and fragment_add() (fragment_add_work()
being static). But, do I need to compile wireshark with debug symbols
or something to get them right?
Also, if we modify the reassembly code to take a tvbuff_filebacked and
reassemble (not the data) in it, we'll have to modify all the
dissectors accordingly, right? I guess that'll have to be done anyways
if we introduce tvbuff_filebacked.
Not necessarily if we can hide the fact in the tvb or reassembly
functions. I think the first step is to find out
how feasible this idea is and an implementation strategy. gziped files,
encrypted files etc may prove the idea not valid.
An alternative is store reassembled packet in file in some way. In
pcap-ng it could be a block option or a new block type pitfalls may be
missdisection change of preferences lost packets etc one would probably
need to be able to reread the original file in some way.
Cheers
Ambarish
___________________________________________________________________________
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
