Re: Filebacked-tvbuffs : GSoC'13

[Ambarisha B <b.ambarisha () gmail com>]

On Thu, May 2, 2013 at 5:17 PM, Anders Broman <anders.broman () ericsson com>wrote:

>  > Just keep all the info in temporary files and clean up the files when
> free'ing the tvb's. In this case, can we use the wiretap to deal with the
> temporary files as well?
>
> The tvb:s only “live” in packet scope so what we need is file backed
> fragment (reassembled) storage (I think)

fragment_data scope is just the reassembly. The reassembled data is passed
to sub dissectors as tvb, isn't it?

Also, "filebacked tvbuff" may not be the right name. What I had in mind was
something like what Evans pointed out in the other thread:

   1.  A tvbuff which knows that it holds a list of
   frame_data/fragment_data and that the actual data is on the disk
   (TVBUFF_REASSEMBLY, maybe ??)
   2. Reassembly would be building this tvbuff
   3. When the reassembly is complete it gives back this tvbuff, to the
   dissector. Since the reassembly is complete, the tvbuff "has" all the
   packet data(though, its on the disk). This will be handed to the
   sub-dissectors.

If the data is backed in a temporary file, we'll have to maintain the
offsets etc in the tvb layer, wouldn't we? That doesn't sound so good. Am I
missing something here?

> ****
>
> > In case of encrypted files, we can have a "large cache" so in the worst
> case we are back to where we are now with them.****
>
> It’s not the file being encrypted it’s the packet, think SSL, it’s
> encrypted per-packet (right?) so each packet needs to be decrypted before
> the fragment can be stored, any protocol with similar behavior ****
>
> Would have the same problem – data can’t be directly accessed from the
> original file as it’s manipulated before the fragment is stored.
My bad, I mean't encrypted packets. What I was thinking is that if the
cache is large enough (as in as large as the packet iself), we wouldn't
have to go to the original file again. All the decrypted packet would be
there in the cache. Anyways, sounds too much like a hack.

Thanks alot for your patience,
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-request () wireshark org?subject=unsubscribe