[pcap-ng-format] Moving forward with pcap-ng

[Guy Harris]

On Jun 26, 2012, at 11:39 AM, Richard Sharpe wrote:

> There are (hardware) groups out there who might be encouraged to use
> the standard if certain changes were made to formats. For example,
> switch/aggregator/etc vendors might like the actual packet data in an
> enhanced packet block (or a new block type) to appear early in each
> encapsulated packet. That is, packet data comes immediately after the
> 8-byte header.

New block type, please.  Let's not change the way a block with a block type value of 6 is to be read.

> This allows such users to reduce the buffering required and start
> pushing the frame data out onto the wire as soon as they have
> assembled the frame to be sent. Once the frame data has been sent they
> can then push out the options (capture timestamp etc) which they can
> assemble while they are transmitting the frame data.
> 
> Of course, I might be off base here, but assembling the additional 20
> bytes required by the interface ID, timestamp high and timestamp low,
> packet len and captured len might be a problem.

Note that they have to know the captured length before they start pushing the packet out, as the total block length is the captured length, plus the length of the extra data, plus padding, and is thus dependent on the captured length.  *Assembling* that extra data might be a problem, but you still have to at least *know* the captured length before you start.

Presumably such a block would be processed by skipping to the end, using the total length, and reading the extra data from the end.  Given that, either the captured length has to be at the *very* end of the block or, at least, must be followed only by a fixed amount of other fields (so it can't be followed by the options), or there has to be something else there to allow the beginning of the extra data to be found.