tcpdump mailing list archives

Re: Proposed new pcap format


From: Hannes Gredler <hannes () juniper net>
Date: Wed, 14 Apr 2004 21:25:42 +0200

On Wed, Apr 14, 2004 at 03:06:09AM -0400, Jefferson Ogata wrote:
[ ... ]
| I think we should take a hard look at 
| whether it's really appropriate to define yet another hard binary file 
                                            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
| format when XML can provide the same functionality with modest storage 
| overhead, and has many added benefits.

jefferson,

we are trying to converge on a sucessor to the current pcap format
which is (practiacally) not extensible at all, mostly due to
absenence of TLV encoding;

so lets not make the mistake and compare apples (a non-extensible binary
file format) with oranges (a extensible ascii/mime/xml) one and
be reasonable ...

proper TLV encoding and decent sizes of the types and values [16/32 bits]
are key to extensible long lasting protocols/formats that meet efficiency,
storage and bandwidth goals;

i really only can speak for routing protocols [which my main expertise]
and all the sucessful routing protocols [BGP,IS-IS,LDP,RSVP] are binary encoded
albeit with a proper, extensible TLV and subTLV [nesting] orientation;
actually distributed systems do live much longer than even simple
file formats ... so one might ask if it does work for distributed systems
why does it not work for storage ? 

i certainly do think that and XML _output_ of the binary file [not storage]
does makes sense however IMHO that does not mandate to store the data
and requiring conversion to a XML tag like structure which may impose
performance constraints especially when you are thinking about capturing
speeds of oc192c and above;

/hannes
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.


Current thread: