On Thu, Jun 17, 2004 at 10:58:39AM +0200, Yann Samama wrote:
> Maybe a short scheme will help :
>
> FILE header
> BLOCK 0 header
> BLOCK 0 data
> pkt header 0
> pkt data 0
> pkt header 1
> pkt data 1
> pkt header 2
> pkt data 2 (not complete)
> BLOCK 1 header
> BLOCK 1 data
> pkt data 2 (continued)
> pkt header 3
> pkt data 3
> pkt header 4
> pkt data 4
>
> So is it possible to have this properly working with the "read" function ?
It should be. You'd have to maintain some state information (I'm
assuming the block header somehow indicates how much data there is in
the block, so the amount of data left in the block would be part of that
state information).
That also complicates the "seek and read" operation - if you do a
seek-and-read to packet 2, it'd have to be able to find out how much
data from packet 2 is in block 0.
You might have to maintain your own data structure giving, for example,
start and end offsets for all the blocks. See, for example,
"ngsniffer.c", which needs to maintain data structures to map offsets in
the uncompressed data stream (which are what the read routine returns
and what the seek-and-read routine takes as an argument) to offsets in
the compressed file. Just as with the compressed Sniffer format, you
won't need to maintain that data structure if you're only reading the
file sequentially (e.g., in Tethereal).