On Thu, Jan 23, 2003 at 11:26:27PM -0000, Laurent ROGER wrote:
> 3°) Is there a "usual" size limitation for capture file (.cap) ?
> Huge file (for example 500Mo) seems to stucks ethereal .
"Stuck" in what sense? Does it just make very slow progress (with the
progress bar), or is it truly stuck?
There's no built-in file size limitation other than one imposed by the
size of file offsets, which are 31 bits plus sign on most platforms
(approximately 2Go or, for Anglo-Saxons, 2GB :-)). There are
limitations due to
1) the frame number being 32 bits starting at 1 (but on
platforms with 31-bit longs the file size limitation will
probably prevent you from having that many frames in a
capture);
2) several data structures being allocated for every frame.
In addition, it dissects each frame as it reads the capture (in order to
build up state it needs to dissect subsequent frames, and to construct
the list of packets in the topmost pane), so reading in captures isn't
extremely fast - very large files could take a while to read.
> I didn't see in the wish list the ability to read big file (no need to
> split it then) , am i right ?
Right.
There is no file size that distinguishes "big" from "not big", so, at
best, one could put into the wish list the ability to read bigger files
(although that depends on what the OS lets you do, e.g. some OSes might
not support files >2Go or >4Go at all), or a reduction in the amount of
memory required per packet (a different widget for displaying the packet
list, which calls back to the application to get the column data, rather
than the current widget which makes a copy of the data for each column
displayed, might help; support for efficient random access to files plus
such a widget might help even more, at the expense of making it
*extremely* expensive to sort the columns on anything other than frame
number, time, and *possibly* address and protocol columns - no way in
heck is it going to be efficient to sort it on the Info column), or a
reduction in the time taken to dissect a packet (I haven't done a
profiled run of Ethereal loading a capture file in quite a while, so
there may be some improvements that could be made - however, many of the
improvements might be to dissectors for particular protocols, and those
problems might not show up unless whoever does the profiled run happens
to have a capture with a lot of packets whose dissection uses the code
with the performance problem.
