Guy Harris wrote:
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.
Well, which we're currently *only* doing with "update list of packets in
real time" captures. That's what I meant with additional work to be
done. If "update list of packets ..." is switched off, the main program
currently don't examine the content of the capture file at all, but
that's needed to get the info for the capture info dialog.
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.
That's a current "design flaw" IMO. If both "capture info dialog" and
"update list of ..." is switched off, you won't get any information
about the current state. Even worse, you don't even get the number of
packets captured, which is a kind of "blind flying" (as we would say in
german "Blindflug"). You can only stop the capture, and then notice that
you've selected the wrong interface :-(
So I really agree that we should display this "how many packets rushing
in" info.
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.
While that's a completely different goal/functionality than the one I'm
currently thinking of.
Regards, ULFL