| -----Original Message-----
| From: Guy Harris
|
| On Sat, Nov 29, 2003 at 12:49:50AM -0800, Blue Boar wrote:
| >
| > Even when you are, you don't
| > have to decode quite as deep for most display filters, no?
|
| Currently, display filters require a full dissection. It might be
| possible to change the display filter code to cut dissection
| short as soon as
| a filter matches, but
|
| 1) that wouldn't help for the initial dissection of a packet, as
| that has to be sufficient to generate enough state for
| subsequent packets (and, for any dissector that calls other
| dissectors, that means dissecting enough to call those other
| dissectors);
|
| 2) that wouldn't help for packets that *don't* match the display
| filter, unless the display filter code can somehow know that
| subsequent protocols won't make a difference (which requires
| that it know for certain what other protocols will, and
| won't, be seen when dissecting), and that won't help in all
| cases;
|
| 3) that would probably not be a trivial change to the display
| filter code.
If the display filter decision logic were able to know that a certain
protocol could *not* run as a payload to another protocol, we might be able
to reduce the requirements on the display filters. Without the knowledge of
the "Decode as" tables, this is "fairly easy" to know. Unfortunately, it is
still depending on humans (like us) to translate those requirements into
code :)
If the display filter language were able to distinguish between protocols
(implying that there would be an obvious and unambiguous field name
hierarchy, like tcp, tcp.srcport, tcp.port etc... all belonging to the tcp
protocol which runs either on top of IPv4 or IPv6 (I'm deliberately ignoring
the tunnelling protocols for now) we could provide "shortcuts" in the sense
that "protocol.field" would require at least the higher-level protocol to
register "protocol". This is OK only if we don't have heuristic
(sub)dissectors... well, it's still possible to simplify the display filter
logic in this situation, but we can put less restrictions here.
And the "Decode as" tables would only complete the display filter logic :)
Regards,
Olivier