[Anders Broman <a.broman@xxxxxxxxxxxx>]

Ambarisha B skrev 2013-04-19 23:01:

Hi,

On Thu, Apr 18, 2013 at 11:31 PM, Ambarisha B <b.ambarisha@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe