On Thu, May 2, 2013 at 5:17 PM, Anders Broman <anders.bro...@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-requ...@wireshark.org?subject=unsubscribe
