Ethereal-dev: Re: [Ethereal-dev] [Patch] tethereal -z tcp,close

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: Tue, 26 Nov 2002 14:54:14 -0800
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.

In this *particular* case (TCP), it might be useful to have the TCP
dissector export that information, as there might be multiple clients
for it (e.g., the TCP sequence number graph stuff could use it as well).

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.