And then one could let the end-user choose other means of moving from one
file to another. My suggestion is to have the "ring buffer" feature and a
new feature called "capture file rotation". One could rotate files for both
features by file limitation, packet count, time since start of capture,
absolute system clock time intervals. This means that the Packet Capture
Dialog should never gray out the "rotate capture file every" option.
An extra feature could be to select the number of files the ring buffer
should manage; this value has to be checked against a minimal (2) and
maximal (64?) value.
Implementation is trivial I think.
Regards,
Olivier
> -----Original Message-----
> From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
> Sent: donderdag 19 juni 2003 0:54
> To: Ian Schorr
> Cc: Laurent Deniel; Heilmaier, Alois; ethereal-dev@xxxxxxxxxxxx;
> ethereal-users@xxxxxxxxxxxx
> Subject: [Ethereal-dev] Re: [Ethereal-users] Questions on
> using ethereal
> / tethereal
>
>
> On Wednesday, June 18, 2003, at 03:22 PM, Ian Schorr wrote:
> > What use is the ring buffer other than generating small, managable
> > files while capturing?
>
> I didn't write the ring buffer code (it was written by the two people
> credited in the AUTHORS file with "Support for stopping capture at
> specified capture file size or capture duration"), and I don't use it
> except when testing fixes to it, but the *two* reason i can think of
> why people would use it are:
>
> 1) they want to do a capture and have multiple smaller
> files rather
> than one big file;
>
> 2) they want to have a capture running continuously,
> waiting for
> something to happen, and when they stop it they don't want all the
> traffic that was captured since they started the capture,
> they want the
> last N bytes or packets or minutes of captured data (i.e., they know
> something will probably happen, they don't know *when* it
> will happen,
> and they want a trace of traffic from shortly before it
> happened up to
> the point when it happened).
>
> The ring buffer may well have been intended for use 2), not use 1).
> For use 1), it's not clear you want a ring buffer at all - you might
> well want to keep *all* the data that's been captured, so it
> would fill
> up a file, close it, and move on to the next file, rather
> than doing as
> the ring buffer code currently does, keeping all the files open and,
> when it fills up the last file, going back to the first file,
> truncating it, and saving further traffic to it.
>
> So if people say they want more files in the ring buffer, the first
> question I'm tempted to ask is "do you want a ring buffer, or do you
> just want Ethereal to keep writing to *new* files as it fills up the
> old ones?" If the answer is the latter, then the right fix
> might be to
> have a mode that does that - said mode doesn't keep files
> open (which I
> presume was done as an optimization in the ring buffer code), so it's
> not limited by the maximum number of open files.
>
> _______________________________________________
> Ethereal-dev mailing list
> Ethereal-dev@xxxxxxxxxxxx
> http://www.ethereal.com/mailman/listinfo/ethereal-dev
>