On Wed, Nov 19, 2003 at 11:01:59AM +0100, Lars Ruoff wrote:
> Ok, i will try to get rid of constructing the protocol tree.
> But does that improve performance
Yes - not constructing the protocol tree for the tap could improve
performance; construcing a protocol tree can be expensive.
> It doesnt change the fact that the whole file does has to be redissected,
> does it?
There are (at least) two ways the tap can work without constructing a
protocol tree when the file is read in:
1) it can be run when the user asks for the list of RTP streams,
and not when the file is read in - that means you have to
make a pass through the capture when the user asks for that
list.
2) it can be run when the file is read in, *but* not require a
protocol tree - that means you don't have to make another
pass through the capture when the user asks for the list.
If you pass a null pointer to "register_tap_listener()" as the "fstring"
argument, it will not require a protocol tree for that tap. That will
require the listener to check the source and/or destination addresses to
make sure they're IPv4 (or IPv6 if you add support for that), and
require it to check "pinfo->in_error_pkt" (unless we change the RTP
dissector to do that, which is probably what it should do).