["Pia Sahlberg" <piabar@xxxxxxxxxxx>]

Hi Jason

>     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.

Ok. I see what you mean.
Yes, definitely, it would be a BUG if the tap system did call the tap again 
just because the user clicked on a packet in the list.
However, since the tap is inside add_packet_to_packet_list() in file.c and 
AFAIK this function is only called whenever ethereal reads a packet from an 
interface or a file.
AFAIK this funciton will NOT be called when the user selects a packet and 
thus the tap system will not be called.



>  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.

That sounds really nice.
I would be interested in seeing if someone  can actually use tap to produce 
an extension and when doing so also
add the missing documentation , what is unclear, so it gets even easier for 
the next one.

Perhaps you could implement a dead simple tap extension for 
tethereal/gtk/gtk2 as the first warming up
excersise?   I am thinking of something like a FrameSizeHistogram which 
would be small and simple.
It could tie in to -z io,    as the patch I sent in a few days ago do. That 
one is not in CVS since I am internet disadvantaged for a week or two more 
and cant do it myself.   Hopefully some of the other developers will check 
it in.

Perhaps something like   -z 
io,fsh,frame,<max-size>,<num-intervals>[,<filter>]    that attaches to 
"frame" tap.

I would be very interested in your experiences when developing a tap 
extension so that I can update the documentation for it.

>     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...

But,  *rs  is a dynamically allocated structure describing all data for a 
specific tap instance.
Even if you start 2 or three separate rpcstat tap listeners, they will all 
have their own unique *rs structure
independently of each others.
The *rs struct is a tap listener specific structure, the tap system does not 
know what it is, it just thinks it is a void*.
*rs is not known nor used outside of tap_rpcstat.c

Please be clearer in describing what you mean above.
Do you mean that you want something like    After packet X is received from 
tap FOO, start tapping 200 packets on tap BAR?
That is simple as well.
Start by setting up a tap FOO to trigger the event "Packet X".
When the FOO tap triggers on event "Packet X", let FOO_packet() callback do 
a register_tap_listener() for BAR.
Then for all further packets in the capture, BAR is used.


>     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"...

display filter and color filter matching are definitely something that would 
fit well inside the tap semantics.
I belive it should be looked into and am doing so.

>   I think that the tap event types may have
> more utility than the tap-writer initially envisions.

The tap-writer, that would be me. :-)


> 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...

The tap core DOES filtering!   But it only does filtering on normal display 
filters.
See what happens if you do   ./tethereal -n -r foo.cap  -z 
rpc,rtt,100003,3,nfs.fh.name==foo -z rpc,rtt,100003,3,nfs.fh.name==bar

It adds two separate tap listeners, each with its own independent *rs 
structure.
The first one registers to the tap core with a "display" filter   
"nfs.fh.name==foo" meaning that the tap core
will only call the _packet() callback IFF the packet matches the filter.
Same for the second instance.


best regards
    ronnie sahlberg



_________________________________________________________________
Broadband?�Dial-up? Get reliable MSN Internet Access. 
http://resourcecenter.msn.com/access/plans/default.asp