Ethereal-dev: Re: [Ethereal-dev] Advice on how to make a protocol grapher...
Guy Harris wrote:
On Thu, May 22, 2003 at 01:34:49PM -0400, Jason House wrote:
If yes, then it's a matter of trying to make what already exists work
in real time... something that I would love to see ;)
If you mean making taps work in real time, updating as a capture
progresses, then note that taps work by scanning through the packets and
processing them sequentially, so, to make taps work in real time, you'd
want to process packets as they arrive.
Yes, that's what I was referring to. In the ideal world, even one step
further... Allowing for a rescan of the packet list even before the
original one finished (since it never truly does in real-time
updates)... ie. if io,stat GUI is used, and a new display is chosen, the
display thread will stop parsing new packets, and go back and rescan old
ones, and then continue on with new and queued packets.
You might not want to require that the list of packets update as the
capture proceeds, although it's not as if you avoid the overhead of
dissecting packets while you're capturing - you need to do that to do a
tap regardless of whether you're updating the display or not; you only
avoid the overhead of updating the list of packets and the display, and
of computing the text for the new columns.
That is a good point. Maybe there could be another checkbox for "Update
taps in real time"... where there is no packet list GUI activity at
all... and thus require a redisection of the packet list when the
capture is stopped.
We could even avoid some of *that* overhead if we went with column-list
widgets that used callbacks to fetch the column text. That would need
to compute the text for the new columns for a given packet only if
1) the display were scrolled and the row for that packet were
scrolled onto the display;
2) you did a sort on the column (NOTE that this would make
sorting on the Info column, and possibly sorting on the
protocol column, *V*E*R*Y* slow in a large file!);
3) we computed the widths of the columns based on the widest
column text, in which case we'd need to compute the text for
*every* column (note that Microsoft Network Monitor, which I
suspect computes column text only when a row is to be
displayed, has fixed-width columns and just puts in a "..."
if the full text doesn't fit - you have to resize the column
manually to see the rest of it - *and* doesn't support
sorting on columns).
Well, is it the storage for the GUI that is the issue or is it the
overhead of having a proto_tree. I might be mistaken, but I think most
taps require the full proto_tree based dissection.
I'm not familiar with the underlying candidate data structures (I
only know the current clist)... but I could imagine that something along
the lines of emacs's lazy-lock could work... Compute the necessary
information when it is needed, and then save it for the next time the
same information is viewed.
Actually, when to compute, and discard the strings could become part
of the preferences... Even something that changes based on capture
size... Like if 100,000 packets would consume all available memory,
then set the packet list memory to no more than 90,000 packets... Small
captures could still go at blazing speed, but then a very large capture
would go much slower. In such a scenario, the sorting algorithm would
become very important. I'm unsure which sorting algorithm would be
best. I am leaning towards quick sort. Quick sort would start out
slow, but then speed up. Others seems like they have a tendency to
cycle through all/random elements too much... I might be wrong though,
or forgot to consider one.
