[Laurent Deniel <deniel@xxxxxxxxxxx>]

Guy Harris wrote:
> 
> > 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.
> 
> Unfortunately, the way the real-time display works is that, in effect,
> it reads the capture file as packets arrive - and operating with a ring
> buffer means, in effect, that packets discarded from the ring buffer are
> "un-read", and there's no provision in Ethereal for "un-reading"
> packets...
> 
> ...and, given that the dissection of a frame may depend (and often
> *does* depend) on what came in the frames previous to it, it's not clear
> how one *can* make Ethereal capable of "un-reading" packets (without
> removing from Ethereal all state information in dissectors, which would
> severely limit their ability to dissect frames).

Sorry, I almost never have interest of dissectors that need to keep state
information from previous frames :-).  But I agree with you. It would be
hard to "un-read" packets.
  
> Furthermore, if we eventually do reassembly without keeping frame data
> around in memory until the capture file is closed (this requires that
> random access to gzipped capture files be made efficient, but other
> things require that as well), "un-reading" frames would cause additional
> problems.

Yes.
 
> I.e., whilst it might be *nice* to have that feature, I'm not sure that
> feature can be implemented in a consistent fashion; "feature XXX is
> nice" doesn't necessarily mean "it's technically possible to implement
> feature XXX in a way that doesn't suck".

I agree, this is why I was proposing the following ... ;-)

> > 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 ...
> 
> Tethereal *already* lets you do that - use "-R" rather than "-f" in a
> live capture.  Ethereal could do the same - although the question then
> would be whether this should be implemented by
> 
>         1) having a check button in the "Capture Preferences" dialog box
>            that specifies whether the filer is a capture or display
>            filter, which is a bit ugly
> 

Or having a capture filter like now and a check button that specifies that
packet that does not pass the current display filter shall not be saved 
as well ...

> or
> 
>         2) having Ethereal treat it as a capture filter if it can be
>            parsed as one and a display filter if it can't be parsed as a
>            capture filter but can be parsed as a display filter, which
>            runs the risk that the people who currently ask the Ethereal
>            list "why doesn't 'ip.addr == 127.0.0.1' work as a filter?"
>            instead blithely use display filters and possibly find that
>            Ethereal can't keep up with the network traffic because it's
>            seeing *every* packet and running the
>            considerably-more-expensive display-filtering process on all
>            of them.

We need both to save CPU time. I.e. a limited capture filter and a more
powerful display filter which could be on option a "second level capture
filter" in user land ...

--
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.