Chris Wilson wrote:
> 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.
Yeah, the trouble is that a "leak" is generally considered a bug, but at
least some of the accumulated memory is being accumulated by design - it
might be possible to avoid keeping some of the memory around, but it
wouldn't be possible to avoid keeping all of it around without losing
useful functionality.
>> 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?
"Should be" as in "that's how it works now", but note that this does *NOT*
involve live graphs, it just involves capturing packets and saving them
away.
>> 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.
That might be doable, although:
1) "just those packets" might not be sufficient to identify them as
VoIP (there might be setup packets other than the "Unknown UDP"
packets that identify them as such) and...
> 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.
2) that part - i.e., having a live capture in progress, saving to a
file and then doing simple dissection with graphs, and then allowing a
full dissection to be done on some or all of the captured packets -
would be a *lot* of work; Ethereal's not architected to make that
easy.
>> 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.
I was thinking of more than just customizing the view in the example I
gave - I was thinking of, for example, an application completely lacking
Ethereal's detailed dissection capabilities, for use as a network
monitoring tool, which "customizes" Ethereal's view by eliminating it. :-)