Ethereal-dev: Re: [Ethereal-dev] mergecap from fifos

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

From: Richard van der Hoff <richardv@xxxxxxxxxxxxx>
Date: Fri, 21 Oct 2005 19:56:19 +0100
Ulf Lamping wrote:
Richard van der Hoff wrote:

Hi,

The attached patch and replacements of wiretap/file_wrappers.{c,h} address the can't-mergecap-from-fifos problem by adding a layer of buffering to capture file access in wiretap.

This trick only works for capture file formats which can be read incrementally in a single pass, but since that includes libpcap, I've found it to be adequate for my needs.

I've found it works pretty well for me, but please do share any comments.


Hi Richard!

Had a (very) short look at your changes, some things comes to my mind:

As I don't know the "incrementally" details of the different file formats, does anyone know which formats won't work, or is this supposed to be used only by specific file types? It's simply a "no go" if existing file formats will stop working.

Of course. Nothing will stop working; I'm just saying that you won't be able to read certain file formats from a FIFO.

Will this slow down file reading?

Short answer: yes.

Slightly longer answer: not by too much, I hope. I've tried to keep the code fairly efficient, and really the only extra operation is a memcpy. Any overhead would be pretty negligible compared with the overhead of disk io.

It's possible that we should only do the buffering when we're reading from a fifo. If anyone wants to implement that, I won't mind ;)

With using GTK2.6, we need to use the GLib functions (e.g. g_open) instead of the plain old open functions. Will this interfere with your changes?

No more than it would with the old code. I've just built my buffering layer on top of the existing abstraction which uses either fopen() or gzopen(): that is the place to insert g_fopen() and co.

If it should be included in the sources, you might split the new functionality into a separate file (e.g. file_buffering.c or such).

I disagree; the idea is that the two or three existing functions in file_wrappers.c should be entirely hidden from the rest of wiretap by the buffering layer.

Thanks for the feedback though!

Richard



--
Richard van der Hoff <richardv@xxxxxxxxxxxxx>
Systems Analyst
Tel: +44 (0) 845 666 7778
http://www.mxtelecom.com