On Wed, 28 Nov 2001 15:47:40 Guy Harris wrote:
> > The display filter code can easily be changed to find an field under
> > *any* protocol, not just the one for which the field was registered.
>
> Hmm.
>
> If you're doing a display filter, you're not interested in most of the
> fields that could be put into a protocol tree, you're only interested in
> a subset of them (unless you've constructed a truly insane filter
> expression).
>
> 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.
Good idea. We'd have to provide multiple dfilters to the proto_tree
routines, to account for dfilters as "display filters" and dfilters
as "color filters".
I wonder, is there ever a need to create a new dfilter and apply it
to an already-created proto_tree, causing this scheme not to work?
It probably doesn't matter, since re-creating the proto_tree is not
too time-consuming.
>
> 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.
>
> (It's conceivable that one could represent display filter expressions in
> a form where you can evaluate individual terms as the fields to which
> they refer are entered into the protocol tree and, in some cases, cut
> short the construction of the protocol tree as soon as you can tell for
> certain whether the expression will evaluate to "true" or "false". For
> example, with a display filter such as
>
> smb.fid == 0x8080
>
> once you've put an "smb.fid" entry into the tree with a value of 0x8080,
> you know it'll evaluate to "true". Obviously, if you see one that
> *isn't* 0x8080, you don't know one way or the other, as the semantics of
>
> {field} {relation} {value}
>
> are that it tests whether *any* instance of {field} is in the relation
> in question to the value, so you can never determine whether a test is
> false until you've build the entire display filter.
>
> That might render this an uninteresting optimization, though, as a
> filter is likely to evaluate to "false" on many packets.)
We would have to denote which dfilters cause the dissection to stop
("display filters") and which dfilters don't cause the dissection to
stop ("color filters").
--gilbert
