Matthias wrote:
>
> Guy Harris wrote:
> > On Mon, Jun 18, 2001 at 02:36:41PM +0200, Matthias wrote:
> > > 2. Dump captured packets to ringbuffer, i.e. only the most recently
> > > captured
> > > packets are available (includes support for multiple dump files).
> >
> > What defines "most recently captured" here? The most recent N packets?
> > The most recent M bytes worth of packet data captured?
>
> The most recent N packets. N depends on configured number and size of
> dump files used for the ringbuffer.
>
>
> We agree with you. To simplify matters we suggest that "Update list of
> packets
> in real time" is not supported when ringbuffering is enabled and vice versa.
>
> The main purpose for a ringbuffer here is to avoid running out of system
> resources (e.g. disk space) when performing long time capturing in order to
> track
> down effects that occur only sporadically.
>
Well I used to think about that a long time ago, but I never had the time to
implement it. I really like the idea to have ring buffering but I also like
the capability to do the real time display at the same time. Why ? simply
because when I want to track down some special traffic or condition,
I want to see the packet display as soon as it arise. Ring buffering was
necessary to save disk space but also memory usage since the filtering
capability at capture phase (e.g. libpcap) is really limited as compared
with the filtering capability as display phase (display filters are much
more powerful than capture filters). So I wonder if the possibility of
ignoring packets (i.e. do not save them in the captured file) based on
the capture as well as display filter would be of interest. In such as case
it would be possible to track down a problem with a complex display filter
in real time without having disk or memory usage problem ...
--
Laurent DENIEL | E-mail: deniel@xxxxxxxxxxx
Paris, FRANCE | laurent.deniel@xxxxxxxxxxxxx
| WWW : http://www.worldnet.fr/~deniel
All above opinions are personal, unless stated otherwise.
