Hi Guy,
Sorry for the half-finished message I sent before. For some bizarre
reason known only to the monkeys who designed it, Evolution binds
Ctrl-Enter to "send message", while "Ctrl-Backspace" is "delete word".
Guess what I did :-(
Only yesterday, I killed my X session by mistake by using
Ctrl-Backspace, when my finger slipped onto the Alt key.
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 dissection is being done, even though the captured packet
list is not being updated?
> > 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)
If they selected a time range that included call setup, and showed all
packets for that time range, and then we switched to packet view with
the appropriate time filter already loaded... would Ethereal dissect all
packets in its capture buffer, or only the ones within the time period?
Would that likely be enough information to identify the VOIP packets
properly?
Even if not, it may not matter so much. Identifying the originating
local IP addresses is probably just as useful, if not more, than knowing
that the traffic is VoIP. If you go up to the machine's owner and see
that she's on an Internet phone call, you will know.
> 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.
I didn't necessarily mean "save to file", but rather "filter by time
interval". And what is with the obsession on saving stuff to files
anyway? :-) I don't want the user to have to save _anything_ if they
don't have a good reason to want to keep the data indefinitely.
> 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. :-)
Well, I like Ethereal's detailed views and dissector. Otherwise I would
be more strongly considering writing the application from scratch than
customising Ethereal. At least then I could work in wxWidgets, which I
already know, rather than learning GTK.
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 |
