Guy Harris wrote:
>
> On Tue, Nov 26, 2002 at 05:44:05PM -0500, Jason House wrote:
> > There is another reason why it might not have made its way into the
> > CVS... It did not use the normal mechanism for a tap to function...
> > The idea is that a protocol should share the tap-specific data rather
> > than have the data extracted from the protocol tree (either manually
> > or via the filtering mechanism)
>
> I wouldn't describe the shared data as "the normal mechanism". There's
> a tradeoff - if you share tap-specific data, the tap stuff will probably
> run faster, as it has to do less work to extract the data; *however*,
> you can only do such a tap if the dissector you're tapping into is
> providing the information the tap wants. If you extract the data from
> the protocol tree, it might involve more work, but you can construct
> taps that do things the protocol dissector writer didn't anticipate, and
> don't have to hack up any protocol dissectors to do it.
I guess I need to choose my words a bit more carefully. Filling a
data structure does increase performance and is generally preferred
when possible... Things such as tap-rpcstat and tap-tcp_close can
get significant performance improvement from using that mechanism.
Listeners that use random fields from random protocols must rely on
the epan_dissect_t instead, but pay the price of speed.
I still wonder if a "if (tap_listener)" analogous to "if (proto_tree)"
will ever pop up in dissector code. So far, I think the overhead of
tap listener specific information is minimal. Dissection might even
benefit from lines like "if (tap_listener || proto_tree)". One
example would be OSPF which might not want to go through dissection of
each and every LSA to provide information for a tap listener that
isn't even being used.
> However, there was a reason why I'd suggested passing the epan_dissect_t
> to the tap callback - ultimately, I'd like to see the plugin mechanism
> enhanced to allow taps, as well as dissectors, as plugins, so that
> people can cook up their own taps and plug them in without having to
> change Ethereal at all, and that either requires that the dissector into
> which they're tapping supply the information their taps need or that
> the tap fetch that information itself from the protocol tree.
Hmmm... I think it would be rare for tap listeners that use fixed
fields to not provide a patch to the dissector... but they may exist.
At the very least, the generic ability to access any field will always
be beneficial to some listeners such as iostat.
I will be interested to see what Ronnie comes up with in terms of some
kind of intermediate mechanism for allowing fast access to certain
common fields such as frame.len as well as slower access to other,
more generic, fields/tap outputs.