Ethereal-dev: Re: [Ethereal-dev] VJ compressed PPP packets ??

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Guy Harris <guy@xxxxxxxxxx>
Date: Wed, 28 Feb 2001 14:34:15 -0800 (PST)
> Now the problems... those damn 'packet window', (why did I
> add that?).

Because it's useful when you're comparing two separate packets from the
same trace?  (That's what I mainly use it for.)

> When there is a packet window open, we have
> tvbuff for both the main display and the packet window 
> active, (same problem for my idea). So, using a list of
> tvbuffs will not work because it will see tvbuffs for
> both the main window and the 'packet window'.  
> 
> I'm stumped, any suggestions.

I was thinking about this a bit - in some sense, what *really* wants to
be tagged with a name is a chunk of raw packet data; if there were an
object that referred to raw packet data, that had a name (and a pointer
to the raw packet data, and perhaps a length), and that were attached to
a tvbuff:

	a "raw data" tvbuff would refer to the object that has the name
	and raw packet data;

	a subset tvbuff would refer to the parent tvbuff's object;

	a composite tvbuff - well, it gets a bit more complicated,
	there, as, if we did reassembly, we might want to have a pane
	for the reassembled packet data, but we're not doing reassembly
	or composite tvbuffs yet, so we may want to address that later
	once we figure out how to do reassembly.

That object might be the "storage array and accessors" to which you
refer.

Initially, there would be one "packet data object", referring to the
packet data read from Wiretap.

When the packet window code does

	DataPtr->pd = g_malloc(DataPtr->frame->cap_len);
	memcpy(DataPtr->pd, cfile.pd, DataPtr->frame->cap_len);

it'd create a new "packet data object".

That code also creates a new "epan_dissect_t"; I'd associate, with an
"epan_dissect_t", a list of packet data objects.  When a new packet data
object is created, it'd be associated with an "epan_dissect_t".

When freeing an "epan_dissect_t", you'd free the packet data objects
associated with it.

We might want to reference-count them, so that if a tvbuff refers to a
packet data object (henceforth referred to as a PDO), the PDO won't be
freed unless no tvbuffs refer to it and no "epan_dissect_t" refers to
it.