I think I phrased #2 (below) poorly. Let me try again...
When you perform an "update capture in real time", the main thread
periodically reads the updated temporary capture file and dissects/taps each
packet that it encounters. The user meanwhile can go back and click on a packet
that was already previously dissected/tapped and it will then be
dissected/tapped again. This revisiting of a packet can potentially wreak havoc
on a tap. I have a particular graphic application in mind where the latest
network topology is graphed in a window on the screen (and optionally
highlighting changes from the previous pictured topology)... Having one window
of "the current network status" and another window for "the current packet(s)
that the user is currently viewing/comparing". In that specific scenario,
separating the first (automated) dissection/tapping and the subsequent
(user-induced) tapping becomes highly important.
I believe that the private listener data (rs for rpcstat), is passed on
every call to the tap, and so a simple mechanism of rs->packet_num will not
work, as it will simply tap a specific # of packets and then stop as opposed to
separating different collections of tap events...
Does this make sense? If the functionality is placed inside the tap, then
it must somehow recognize which type of event has caused the tap call
(potentially via info in pinfo that is already passed in) and act if
appropriate. The problem I see with doing that approach is that the tap must be
smart enough to separate tap event types. To me, it seems that things like the
display filter (for tapping) and filtering by tap event type fall into the same
category of "handled elsewhere"... I think that the tap event types may have
more utility than the tap-writer initially envisions. If the tap core handles
all filtering, then it empowers the user and keeps the taps from having to
change with each new extension of tap filtering...
Pia Sahlberg wrote:
> Hi Jason
>
> >2)
> >I can envision the need for a more selective tap calling trigger than a
> >packet of the right type being encountered. It would be nice to have a
> >tap listener called the first time that a packet is processed (or every
> >time except the first time). I imagine that this might be easy to do
> >based on pinfo, but somehow I think that such functionality should not
> >be inside the tap listener, but outside of it.
>
> Hm.
> On this I dont think I agree. I actually think that this kind of semantics
> should be placed in the tap-listener itself.
> But it is simple to implement but it does not require using pinfo structure.
>
> To add the only-use-first-packet semantics to tap_rpcstat.c this is as
> simple as
> 1, add "int packet_num;" to the definition of rpcstat_t
> 2, set packet_num=0; where the rpcstat_t structures is allocated.
> 3, add rs->packet_num=0; to the beginning of the _reset() callback.
> 4, add rs->packet_num++; if(rs->packet_num>1)return FALSE; to the
> _packet() callback.
>
> simple as that.
>
> Since this kind of semantics is so simple to implement in the tap-listener I
> think it should be kept there
> so we dont add complexity to the tap layer itself (for functions that only
> few taps will use?)
>
> best regards
> ronnie sahlberg
