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.