Wireshark · Ethereal-dev: Re: [Ethereal-dev] Redesign of the WHOLE Ethereal main menu

[Guy Harris <guy@xxxxxxxxxxxx>]

On Sat, Nov 29, 2003 at 12:49:50AM -0800, Blue Boar wrote:
> Right, I was thinking about the ones that just aren't on the screen at the 
> time, when you're not using a display filter.

The current widget used for displaying the packet summary requires that
the text for every row be generated when the row is added to the
display, regardless of whether the row happens to be displayed or not.

This means that, in order for it to even be *possible* to see the
summary line for a packet by scrolling that widget, the packet has to be
dissected.

At some point we might have a widget that will dissect the packet "on the
fly" in order to generate the column text.  However:

	1) Ethereal will still have to, before dissecting a packet for
	   the first time, dissect all packets before it, as Ethereal
	   dissection is stateful (if it weren't stateful, many packets
	   it can currently dissect wouldn't be dissectable, as the
	   correct dissection of those packets depends on information
	   obtained by dissecting earlier packets);

	2) Ethereal will still have to read in those packets so that it
	   knows how many packets there are, so it (or, rather, the
	   widget it uses to display the packet summaries) can make the
	   scrollbar work to show you those packets.

> Even when you are, you don't 
> have to decode quite as deep for most display filters, no?

Currently, display filters require a full dissection.  It might be
possible to change the display filter code to cut dissection short as soon as
a filter matches, but

	1) that wouldn't help for the initial dissection of a packet, as
	   that has to be sufficient to generate enough state for
	   subsequent packets (and, for any dissector that calls other
	   dissectors, that means dissecting enough to call those other
	   dissectors);

	2) that wouldn't help for packets that *don't* match the display
	   filter, unless the display filter code can somehow know that
	   subsequent protocols won't make a difference (which requires
	   that it know for certain what other protocols will, and
	   won't, be seen when dissecting), and that won't help in all
	   cases;

	3) that would probably not be a trivial change to the display
	   filter code.