Wireshark · Ethereal-dev: Re: [Ethereal-dev] [Patch] revised: tap-tcp_close

[Guy Harris <gharris@xxxxxxxxx>]

On Wed, Dec 04, 2002 at 10:22:17AM -0500, Jason House wrote:
>   As guy points out, that functionality is still useful... certain taps
> rely on a complete edt/proto_tree structure...  but the ones that are
> most like the originally envisioned functionally would benefit from
> getting called immediately.

You still don't need queuing for those - they'd be called immediately
after the dissection completes.

>   Also, I believe one of the concepts with the tap listener system was
> to allow tap listeners calls to occur in a lower priority thread than
> physical packet capture...

I think the idea is that tap code that updates the display occurs in a
lower priority thread, not code that actually processes the packet data
- you can't defer the tap listener calls beyond the point at which
Tethereal or Ethereal starts dissecting the next packet, but you can
defer display updates.

> Guy Harris wrote:
> > Passing the epan_dissect_t might not be useful except for tap listeners
> > not tapping off of a dissector, as the protocol tree wouldn't be
> > complete; those listeners might be called after the entire dissection is
> > complete.
> 
> In fact, if a tap listener is called after incomplete dissection and
> performs a search by using epan_dissect_t, couldn't that make later
> searches for the same item have incorrect results?  I believe that edt
> caches the results of searches and only performs new searches...

What's a "search"?