Ethereal-dev: Re: [Ethereal-dev] Can the the ethereal capture be done to a memory buffer, not

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

From: Guy Harris <guy@xxxxxxxxxx>
Date: Thu, 21 Jun 2001 11:41:15 -0700 (PDT)
> Currently (at least on my Win2K), when ethereal captures, it saves that data
> into a file.

It does that on all platforms.

> This really slows things down (up to a point it is not useful
> for me). Can it save it to a memory mapped file,

It probably could, on platforms that support it, although note that

	1) if it's a memory-mapped file, what you save is
	   userland-to-kernel copy time (and "standard I/O library"
	   userland-to-userland copy time), and not necessarily disk I/O
	   time;

	2) there are platforms on which memory-mapped and read/write
	   access to files won't necessarily get consistent answers (at
	   least some UNIX-flavored OSes don't have unified buffer
	   caches/page pools, so they might not give consistent answers,
	   and an admittedly-old Win32 Programmer's Reference from
	   Microsoft says of MapViewOfFile() "A mapped view of a file is
	   not guaranteed to be coherent with a file being accessed by
	   the ReadFile or WriteFile functions." - although the "Inside
	   Windows NT" books I've read seem to imply that NT has a
	   unified buffer cache/page pool, so perhaps that disclaimer
	   was put in to handle *puke* Windows OT, i.e. 95/98/ME).

> or a buffer in memory

It could do that.

> (perhaps add it as an option

Capturing to an in-memory buffer would *HAVE* to be an option - it's
unacceptable to limit Ethereal's capture size to the available address
space size on the machine.

Now, another possibility would be to have it capture to the buffer and,
when the buffer fills, write to a file and rotate the buffer (or have
two buffers and flip them) - but that's essentially what we do now,
albeit without the "standard I/O library" copy, and with a larger write
size (which runs the risk of inserting brief periods of significant
capture latency).