[Ulf Lamping <ulf.lamping@xxxxxx>]

Guy Harris wrote:

> OK, so is the idea that you have two independent displays:
>
>     1) the packet list/details display (main window);
>
>     2) the capture info dialog, showing counts/percentage bars for 
> various types of packets;

Yes, just as today.

> and you can do a capture with:
>
>     the packet list display updating as packets arrive, and the 
> capture info dialog displayed;
>
>     the packet list/details display updating as packets arrive, and 
> *no* capture info dialog displayed;
>
>     the packet list/details display *not* updating as packets arrive, 
> and a capture info dialog displayed;
>
>     the packet list/details display *not* updating as packets arrive, 
> and *no* capture info dialog displayed;
>
> with the last of them, at least, showing a count of packets received, 
> which updates as packets arrive, and with the main process, rather 
> than the capture process, doing all display updates?

Exact.

> All of those, except for the last, require that the main process read 
> from the capture file while the capture is in progress, so, to 
> minimize packet drops, you have to use the last, with no updates done 
> other than a count of packets arriving.

Yes, just as today.

> Also, the third of them is a bit odd to implement - would it just 
> freeze the packet list display, but add packets to it, and then thaw 
> the packet list display when you stop the capture?

I don't tend to fill the packet list already at that stage (because of 
the machine load to do that). It should work just as today, loading the 
packet list when the capture is stopped. That needs some redesign of the 
capturing engine in the main code, yes.


Summary: The capture process won't show *anything* by itself. It will 
only provide information to the main process, with the following 
messages (copied from capture_sync.c):

#define SP_FILE         'F'     /* the name of the recently opened file */
#define SP_ERROR_MSG    'E'     /* error message */
#define SP_PACKET_COUNT 'P'     /* count of packets captured since last 
message */
#define SP_DROPS        'D'     /* count of packets dropped in capture */.

This way we don't need to tell the capture child anything about which 
mode Ethereal is currently using.

However, we might need a command line option for the capture child, if 
it's used as a standalone tool, but that's a different story.

Regards, ULFL