[ntar-workers] PacketBlock, PacketsBlock, GoPBlock

[Alexander Dupuy]

>> - I'd make mandatory at least one GoPBlock type, "old-pcap", that would 
>> correspond to the old 4-word pcap header format (ts_sec, ts_usec, len, 
>> caplen), followed by the captured data. This will allow fast conversion of
>> old pcap traces to the new format.

Gianluca Varenni replies:
> Uhm, why adding such backwards compatibility? I don't see a big issue in
> converting the old pcap format in the new one, converting every single
> old-pcap header in the pcap-ng blocks (it can be done offline). Instead,
> having another type of packet block adds unneeded complexity to either to
> ntar, or to the app sitting on top of it.

One reason to support an old-pcap format compatibility mode might be to support 
cases where new and old-style captures are accidentally concatenated.  I'm not 
saying that it should be done, just that such mismatched concatenation will 
happen, and if it doesn't make things intolerably complicated, it could be useful.

Incidentally, one of my pet peeves with the existing tcpdump capture format is 
that there is no consistent convention for file extension for these, I have 
seen .dmp, .dump, .tcp, .tcpdump, random others, and no extension at all.  If 
possible, it would be really nice if the ntar library would use a default file 
extension (perhaps overridable by an application or user) for all files that 
are generated.  Having some consistency for this would greatly reduce the 
likelihood of accidental concatenation of new and old trace format files.

At the very very least, there should be a suggested file extension in the NTAR 
specification.  (I don't really care if it is .ntr or .ntar or something else, 
as long as everybody uses the same one.)

@alex
-- 
mailto:dupuy at counterstorm.com