Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Ethereal-dev: RE: [Ethereal-dev] Capture ringbuffer behaviour, 2nd proposal

Note: This archive is from the project's previous web site, ethereal.com. This list is no longer active.

From: Biot Olivier <Olivier.Biot@xxxxxxxxxxx>
Date: Mon, 1 Mar 2004 17:16:52 +0100
|From: Lars Ruoff
|
|From: "Jason House"
|> Both approaches (I believe) would separate
|> "Capture Files" from "Capture Limits"...
|> I think Biot's comments was just the
|> "Capture Files" section.

Correct.

|The point is that if you use a maximum file number
|but do *not* use the ring buffer, then it
|effectively limits your overall capture -

Correct: for example limit to 5 files and set next capture file every 300
seconds. This yields a capture to 5 files, which will stop after 30 minutes.

|so my logic was that it should go into capture
|limits!

I partly agree. The funcitonality is similar but different :) In the example
you state and I gave, you effectively move to a next file when the "file
rotation condition" is met.

Do we consider "file rotation condition" and "capture stop condition" as
mutually exclusive or as complementary? Today it's the latter, and it's OK
to remain so.

I however agree that the widget is probably the most cumbersome of Ethereal
today :) but it is not that easy to find a better solution. For this reason,
I posted a proposal where you must enable multiple-file capturing with a
check box. I see a total implementation as follows:

File: [_____________] [Browse button]

[a] Write to multiple capture files
    (b1) Next capture file every [___[100]]<rotating list> packet(s)
    (b2) Next capture file every [___[100]]<rotating list> kilobyte(s)
    (b3) Next capture file every [___[300]]<rotating list> second(s)

    [c] Maximum number of capture files: [2]<rotating list>
        [d] Overwrite oldest capture files when maximum
            number of capture files has been reached.

[e] Specify a total capture limit
    (f1) Stop after [___[100]]<rotating list> packet(s)
    (f2) Stop after [___[100]]<rotating list> kilobyte(s)
    (f3) Stop after [___[300]]<rotating list> second(s)

I think this UI layout is a compromise between intuitiveness and complexity.
If check box [a] is not checked, then all controls (b), [c] and [d] must be
grayed out (deactivated). The same applies to (f) when [e] is not checked.
Doing so allows the end-user to see what happens. If they want a global
capture limit, they need to enable it and choose a limit type. The same
applies if they want to use more than one capture file.

Regards,

Olivier