On Fri, Oct 13, 2000 at 09:15:44AM -0400, Reimer, Fred wrote:
> I'm not sure I understand you. It was my understanding that the process
> size SHOULD grow while it captures traffic. Doesn't it keep all the
> captured packets in memory? How could it stay the same size if it did keep
> them in memory? You'd have to pre-allocate huge amounts of memory that you
> may not even use, as you could just be loading up Ethereal to load in a five
> packet capture someone sent you. I think this is normal behavior.
No, Ethereal does not keep all the captured packets in memory. What
it keeps in memory are:
1. The summary information for all packets. This is the single-line
of information you see about each packet in the top pane
of the Ethereal GUI.
2. The full decode of the currently selected packet. That's what you
see in the protocol tree and hex dump panes of Ethereal.
As the user selects other packets, the data for those packets is read
from the trace file, dissected, and displayed in the protocol tree and
hex dump.
It turns out that #1 uses a lot of memory, thanks to GTK+.
> Now, it does bring up a different issue. While I was analyzing a 60MB
> capture file for work I noticed that, on my Windows 2000 box, Ethereal took
> up about 144MB (or somewhere around there, definitely more than 100MB). I
> have 256MB on my computer, so it only thrashed a little (NT takes up loads
> of memory just for the OS). But, what would be the possibility of keeping
> the packets on disk until they are needed? I don't think you'd be able to
> do this with compressed files, but I'd be more than willing to "uncompress"
> compressed captures temporarily if it would drastically reduce the memory
> footprint. In order to effectively work with large captures I have to put
> them on my SPARC box with 2GB memory. This seems to be an excessive
> requirement.
Guy is working on a replacement to the GtkCList widget, which would
remove the requirement to have all the summary lines in memory at once, but
loaded when needed.
> I was thinking that Ethereal could "prescan" capture files and create a
> linked list of info records for each packet in the file, probably containing
> nothing other than the offset in the file where the packet starts. If the
That's what we do with the frame_data struct in packet.h, although it
has more than just the file offset.
> 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
