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

[ronnie sahlberg <ronniesahlberg@xxxxxxxxx>]

Hear hear.


I agree 100%


On 6/27/05, LEGO <luis.ontanon@xxxxxxxxx> wrote:
> 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??
>