On Sun, Jul 15, 2001 at 11:37:09PM -0700, Guy Harris wrote:
> On Sat, Jul 14, 2001 at 06:38:02PM -0400, Ed Warnicke wrote:
> > Yes. For example one might put in a post dissection point into the
> > api so that I could register a function with ethereal that gets called
> > after a packet is dissected. Then I could add a plugin that would
> > query each dissected packet to gather statistics.
>
> Hmm.
>
> Would this be for use when Ethereal first reads a capture file, or would
> it be for, say, a Tools menu item that makes a new pass through the
> capture?
Could this be handled in the same manner as UI events?
When user clicks on a packet in the packet list ethereal performs
dissection and displays the protocol tree for that packet. Could this
model apply to plugins, too? When a plugin needs to dissect a packet it
would be dissected and returned to the plugin. The scheme could be
optimalized in a number of ways. E.g. if some performance can be
obtained by dissecting all of the dump at once instead of dissecting
packets one after another as plugin code requests them then the ethereal
plugin API could provide a plugin with a way of telling "I'm going to
need the protocol trees for all of the packets so do it now". Or, the
dissection process could consist of separate stages so that if a plugin
just needs to compute some Ethernet stats it can request dissection of
link layer only - there's no need to bother with full dissection of e.g.
SMB headers in that case. Applying this to my TCP graping code, if the
core could just give me a pointer (or an offset) into the raw packet
data where the IP header begins I would be perfectly happy and yet a
better part of expensive full dissection would be avoided. Once I have
my IP hdr pointer I can do the rest of "dissection" very efficiently
myself.
pvl