Wireshark · Ethereal-dev: Re: [Ethereal-dev] Re: NTAR - PCAP next generation dump file formatimplementation

[LEGO <luis.ontanon@xxxxxxxxx>]

I was not clear at all in my last mail so I'll re-expose myself.

Please note that I'll refer to "chunks" for segments of data
containing more records and to "records" to refer to atoms. I find the
term block confusing (in my forma-mentis a block seems something that
contains more records).

The essential point I tried to make is to have the marker-records at
predictable locations in the file.
That would be N*chunk_size bytes.

To archieve that we need:
A padding record to fill in the space between the last packet and the
location of the next marker record.
And, a marker record that tell us what we have so far.

Another point is not to have to seek backwards to fill in fields while
dumping. Neither I like the Idea of having to keep a whole chunk in
memory nor to have to keep more than few very essential state
variables.

I think either the file header or the HSB should tell which chunk-size
we are using.
The whole dump-file should use one an only one chunk-size.

On 6/27/05, Gianluca Varenni <gianluca.varenni@xxxxxxxxx> wrote:
> In general, I prefer your solution over Ronnie's one: the basic idea of
> pcap-ng was to create not too much nesting in the file, so at the moment we
> basically have two levels, sections and blocks. In the future it's
> possible/probable that we will have some nesting, especially to support
> compressed and cyphered blocks.

I like it that way. Nesting stuff would mean either to seek back to
write the length or to keep in memory a whole meta-record before
writing. I do not like either solution.

[snip]
> In my opinion the marker should contain the following informations
> - number of packets up to the next "marker block"
This is a forward reference
> - number of bytes up to the next "marker block"
my point is we should know this before even reading the first marker-record.
> - timestamp of the first and last packet up to the next "marker block"
I would put those before the marker record.
> - offset to the next "marker block"
In my scenario we know it beforehand 
> - other??