Ethereal-dev: Re: [Ethereal-dev] Simple Extension API, patch for tethereal and rpcstat example
Hi,
Small updates to the rpcstat example in the patch.
Better comments and a workaround to the performance problem by doing the
filtering explicitely
inside rpcstat instead of asking the tap subsystem to do it for us.
The performance problem still exists and will affect such applications that
just must use
filtering. (well, its not that bad, but its unnessesary cpu cycles wasted,
and you will notice it)
The workaround in rpcstat is not to use filtering at all in the tap layer
and thus performance is
not affected at all.
The reason for the performance problem is that i want to apply a (display)
filter for each tap
and the only way I could do that was by copying the code in file.c that
applies a display-filter
(by doing a full dissect of the packet!). Thus, tap may want to apply
multplie display filters on the same packet. once for each tap application.
If it would be possible in tap to only dissect the packet ONCE and then just
reapply the filters over and over that would solve the performance problem.
I dont have sufficient good understanding (or any atl all) in this
particular area of ethereal so I dont know if it is possible or not.
Perhaps i should remove the filtering capabilities in the tap layer, but
that would restrict
its uses. Perhaps color-filtering (which would require filter capability)
could piggyback on the tap api and thus lose all the code in say file.c
which today does what the tap api could do for it instead. less code, less
maintenance.
I would want to check this patch in the next few days so that I can resync
my trees with cvs
again and start looking at what the current state of glib2/gtk2 is. I
understand from the mailinglist
that it mostly works right now and ethereal with glib2 (and gtk2) is
useable.
If anyone has any objections or is unhappy with the api exposed to and used
by tap-rpcstat.c
please tell me.
rpc-stat for gtk would be very useful.
Attachment:
tap.diff
Description: Binary data
