Hi Guy,
On Sun, 2006-04-09 at 19:47 -0700, Guy Harris wrote:
> It's a question of what Ethereal does *while* it's capturing.
>
> If it's dissecting packets as they arrive, it will accumulate memory - I
> wouldn't call that a "leak" unless the memory in question can be safely
> discarded at some point in the process of capturing but isn't being
> discarded.
Sorry, I should have been clearer that by "leak", I meant that memory
usage would grow without bounds while the application was capturing, and
the only solution for the user would be to discard all their captured
data (effectively, restart the application). In a continuous monitoring
scenario, that would look an awful lot like a memory leak, even if it's
not technically one.
> If it's *not* dissecting packets as they arrive - i.e., if you're *not*
> doing an "update list of packets in real time" capture - it shouldn't be
> doing session tracking or any of that stuff, it should just be saving
> packets to a file for future dissection, and *possibly* doing some *very
> quick* dissection for the capture window's percentage bars.
By "should be", do you mean that's how it works now (which seems to be
ideal for this purpose) or how it might work in the future?
> If the intent is only to do *simple* graphing - i.e., graphing that does
> *NOT* involve a full dissection of every packet, which means no state
> information, no matching of requests and responses, and no recognizing
> of protocols if it requires human intervention or analyzing a packet
> that sets up a connection to see what future traffic would be - then
> that could be done in the same way that we do the percentage bars, by
> having, for *some* protocols, simple dissectors.
Yes, I think that's all that's necessary.
> Note that many VoIP protocols might require human intervention, or
> analyzing packets that set up connections, so this might not be able to
> figure out how much traffic is VoIP traffic, unless the "simple"
> dissection can analyze packets that set up connections.
How about if the user could quickly identify "Unknown UDP" as the source
of a large amount of traffic on their network, and then switch to either
a stream view, or packet view, of just those packets, which can dissect
them and identify them as VOIP? That would seem to work for me.
I'm considering that the user would often select a bunch of packets out
of the capture buffer based on time interval, by dragging over an
interesting section of the traffic graph (such as a flat top). Detailed
analysis could then be performed on that traffic alone.
If they select another area, the analysis of the previous selection
could be dropped from memory before the new one is computed. That way,
there is no need for the memory used by detailed analysis to grow in
proportion to the amount of data captured.
> Once this is done, however, the question would then be "how much of
> Ethereal is left"? That sort of graphing might also be useful for
> current Ethereal applications (i.e., those that involve doing packet
> capture and detailed dissection), but you might want an application that
> does the simple dissection and graphing but *not* the detailed
> dissection, which might share code with Ethereal but not be Ethereal.
I was considering that as well. I certainly have no objection to
building an application that customises Ethereal's view significantly,
to make it easier for novices, and to calling it something other than
Ethereal. I hope that it could be merged with Ethereal's code base and
maintained together.
Since I can read packet traces, I would personally like the ability to
switch between the bird's eye and the detailed packet view at will. I
don't yet know how many other network admins would appreciate that.
> Note also that a monitoring application might not want to save packets
> to a file - it might just want to read them and discard them.
Yes, that's why I was also proposing implementation of the in-memory
ring buffer, which is already on the wish list.
Cheers, Chris.
--
___ __ _
/ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |