[Guy Harris <guy@xxxxxxxxxxxx>]

On Oct 20, 2003, at 1:40 AM, Biot Olivier wrote:

> Maybe we should compute reassembly information on the 1st
> pass of reading a capture, so that we have an approximate
> idea on the amount of memory we'll have to allocate again
> for the actual reassembly.

How would that help?  The reassembly is done on the first pass, so if 
you don't have enough memory, you find that out when reading the 
capture in - if you don't have enough, you won't be able to read the 
capture.

> Or we could enhance the tvbuff and reassembly code so that it
> doesn't always duplicate memory at reassembly, but works with
> linked lists that are hidden to the developer by the familiar
> helper functions.

How would linked lists help?  If you mean "just make a list of the data 
from the un-reassembled frames", you still have all *that* data to keep 
around.

If we could guarantee fast random access to the capture file, we could:

	on the first pass, discard the reassembled packet data once we've 
dissected the packet, and just keep around information about frames, 
and offsets within frames, from which that data came;

	on subsequent passes, when reassembly is to be done, read in the 
relevant frames and construct the reassembled data, freeing it when 
we're done with the frame.

Guaranteeing fast random access to the capture file requires redoing 
the way we handle gzipped captures, so that we keep enough compression 
dictionary information around to be able to restart the decompression 
process at various points in the capture file.  I think this is doable, 
but I haven't had time to do it.