[Gilbert Ramirez <gram@xxxxxxxxxxxxxxx>]

So, the change to have the dfilter code look at the entire tree
for fields, instead of just in the sub-trees of the protocol registered
as the parent of th efield, is trival. I have made the change in my
local CVS copy. That's the un-optimized version.


On Wed, 28 Nov 2001 15:47:40 Guy Harris wrote:
> 
> If the display filter compiler built a list (array, whatever) of all the
> hf_ values being tested by the current display filter, the code to build
> the protocol tree could, if that list isn't empty (which it would be if
> there are no plans to evaluate a display filter expression), check, when
> putting an item into the protocol tree, whether the item's hf_ value is
> in that list and, if so, add the protocol tree item to a list attached
> to the entry for that hf_ value.
> 
> Then there wouldn't be a need to scan the protocol tree to evaluate a
> display filter - the information needed for the display filter would
> already be available.

As for this optimized version, as Guy describes, the proto_tree_add()
functions need to have the access to list of fields that the dfilters
are interested in. I plan on storing this list of fields in the dfilter
object itself, so that means that the proto_tree_add() functions
need access to the dfilter objects.  I'd hate to have to pass a new
object to the proto_tree_add() functions, so one idea to accomplish
this is to re-design the proto_tree object, which right now is just
a GNode.

If the proto_tree object could store the information it needed about
which fields are interesting to the dfilters, then no more arguments
need to be passed to the proto_tree_add() functions. What it means
is that after the creation of the initial proto_tree object for
a packet dissection, the applicable dfilters would have to be
"registered" with that proto_tree. Then dissect_packet() can be
called.

If I'm going to re-design the proto_tree object, what about doing it
right? The only reason the proto_tree is a GNode is that it was
a direct translation from a GTK-based tree object to a GLIB-based
tree object, in an effort to divorce the dissector code from GTK.
The proto.c code has always maintained a somewhat artificial
requirement that "protocols", to be found, must reside at the
top-level of the proto_tree. As such, perhaps what is needed
is, instead of a tree-based structure, is a list of trees.
That is, the top-level GNode* gets replaced with a GList*... a list
of protocol subtrees.  This would require some changes in
code that analyzes proto_trees (e.g, proto_hier_stats), but to me
a list of trees is a more realistic mapping of a protocol
dissection. I remember a loooong time ago Richard Sharpe had
some ideas on post-Ethereal-1.0 work, and his implementation
was similar... a list of protocols.

Now, to make things even more complicated, another concept
we might introduce is, for lack of a better name, "tunnels". Or
maybe "strata" is a better name.   This concept is an effort to
aid the analysis of tunneled protocols.  Every time a new
tunnel exists in a packet, a new "tunnel" or "stratum" data structure
exists for it. Simple, non-tunneled packets have one "stratum":

Stratum 0
	Ethernet
	IP
	TCP

Tunnelled packets have two strata:

Stratum 0
	Ethernet
	IP
	TCP
	SOCKS
Stratum 1
	TCP
	TELNET

Ad nauseum:

Stratrum 0
	Ethernet
	IP
Stratum 1
	IP
	TCP
	SOCKS
Stratum 2
	TCP
	HTTP

This would make it easier for Ethereal to concentrate on different
strata. If the user wants to "collapse" all strata into one, to see
the final results, click a button. If the user wants to concentrate
on stratum 0, then *that* info is shown in the packet list.
That is, I'm looking for a replacement for having to
call col_set_writable()... let the libethereal code, not the
dissector, decide which info to show.

Hmm, would we have to handle multiplexing protocols here as well?

Stratum 0 --> Stratum 1a, 1b ??

--gilbert