[dist list trimmed]
As you can probably tell, I didn't read all the source code before making
some assumptions about what Ethereal kept in memory. I just thought that to
have a process size of over 144MB when the packet trace was "only" 60MB it
HAD to be
keeping everything in memory.
More comments below.
> -----Original Message-----
> From: Gilbert Ramirez [mailto:gram@xxxxxxxxxx]
> Sent: Friday, October 13, 2000 9:50 AM
> To: Reimer, Fred; Harald Tveit Alvestrand; ethereal-dev@xxxxxxxx
> Subject: Re: [Ethereal-dev] Memory leak of ethereal-0.8.12
>
> > Either that or simply keeping a cache of a reasonable size,
> say 16-32MB,
> > that "close" packets in relation to what is actively being
> displayed, would
> > help. Something needs to be done so that large packets
> traces can be
> > handled.
>
> Coincidentally, I was talking with Mike Hall yesterday about this
> very same subject. I plan to add two things to Ethereal.
>
> 1. The ability to request a range of packets by packet
> number. That is,
> from the command line and from the File|Open dialogue, you could
> request packets 10000 - 15000, or any range you want. The neat
> thing about that would be that the packet numbers in the GUI
> would be correct. Your first packet would be shown as 10000.
>
> 2. Allow Ethereal to detect that the file it is opening is large, and
> prompt the user for a possible range of packets. This would
> be user-configurable, of course.
>
> #1 is easier to implement than #2, so I'll do that first.
>
> --gilbert
(this may already be a feature or discussed on the list, so I may show more
ignorance here ;-)
3. Ability to specify a filter on the command line to "trim down" a capture
file into another capture file, without having to load the whole file in
Ethereal just to specify the filter and save it as a new file before
exiting.
4. Ability to specify a range of packets and save them to a new file,
without loading the GUI.
Question:
If a major memory hog is the GTK+ list that displays the summary info, would
the tethereal "terminal" version be >>significantly<< more able to handle
large packet traces? I can test this myself, obviously, but if you have a
quick answer (yes or no would suffice)...
Fred Reimer
Eclipsys Corporation
