Hi Guy,
On Mon, 2006-04-10 at 18:43 -0700, Guy Harris wrote:
> 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.
OK, understood. I hope I can find a way to only allocate that memory
when the user actually starts to do detailed analysis of a bunch of
packets, and discard it when they've finished (and go back to "normal"
graph-only mode).
> "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.
Does that mean that when a live graph (such as the IO graph) is visible,
the additional tracking is
>
> >> 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. :-)
>
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>
>
> !DSPAM:443b09ba277868982442979!
--
___ __ _
/ __/ / ,__(_)_ | 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 |