Ulf Lamping wrote:
While looking at the capture_loop.c code, I'm asking myself if it's such
a good idea to that the capture info dialog (packet counters) is
implemented there.
I think it's better to move this functionality into main.c (and
implement it much the same way as the current "update list of packet in
real time" is done.
This has some advantages:
- removing possible security risks from the actual capturing code
- the capture loop don't need to handle any GUI related code e.g.
"main_update()", (slightly?) increasing it's performance
- no dependencies of capture_loop.c to the epan library (I've tried,
it's true)!!!
- simplifies capture_loop.c
and some disadvantages:
- some overhead of opening/loading the capture file content if the
capture info dialog is actually used (which is currently not needed, as
the required data is present in the capture loop).
- slightly increasing complexity in main.c (however, will be similar to
the code used for "update list of packets ...", or probably even share
some code)
Summary:
the actual capture code will be simplified, it will be more secure and
the capture performance will increase (packet drops may decrease).
If you're doing an "update list of packets in real time" capture,
there's no extra overhead, as you're already reading the capture file
while capturing, and doing a dissection. In fact, you could even let
the user specify what protocols they want counted, so you could say
"show me how many HTTP packets you've captured" or, if you let the user
specify *arbitrary display filters* for counters, "how many HTTP GET
requests for a URL containing 'foobar'" have been captured.
However, if you're *not* doing an "update list of packets in real time"
capture, the capture will do more work if the counters are updated in
the main process than it does now, as it'd have to read the capture file
while capturing, which we're currently not doing with "update list of
packets in real time" captures.
If non-"update list of packets in real time" captures are
If you want to capture as fast as possible (with the lowest packet drop rates),
the feature should be "off".
captures, then perhaps those captures shouldn't read the capture file
while capturing, and shouldn't bother maintaining *any* packet counters,
except perhaps for count of packets captured - in which case, it might
drop even fewer packets, as all it's doing is moving data to the capture
file without looking at *anything* in the packet, and maintaining only
one counter in a dialog box, with no percentage bar.
(At least some versions of Microsoft Network Monitor have two capture
modes, one where they display all sorts of packet counts and percentage
bars in the main window, and one where they display only a dialog box
with a packet count and stop button; the latter mode is for "reduce the
overhead of capturing" captures - it even forcibly minimizes the main
capture window.)
So maybe we should, in "Update list of packets in real time" mode, let
the user specify what packet types they want counted, with a collection
of display filters (of course, the percentages wouldn't be guaranteed to
add up to 100% - if you have a count of IPv4 packets and a count of TCP
packets, some packets might be both), and, in "don't update list of
packets in real time" mode, just display a packet count and stop button.