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

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

Date Index Thread Index Other Months All Mailing Lists
Date Prev Date Next Thread Prev Thread Next
From: Blue Boar <BlueBoar@xxxxxxxxxxx>
Date: Sat, 29 Nov 2003 13:37:05 -0800
Guy Harris wrote:

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.


I assumed that was the case, or else it wouldn't behave that way now.


At some point we might have a widget that will dissect the packet "on the
fly" in order to generate the column text.  However:
That's what I figured would have to be done. Looking at the small bits of performance gain you guys are getting here and there, I'm guessing that all the easy tweaks have been done. 



	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);
How about being able to go back far enough to dissect the current row? I.e. dissect it, decide that it belongs to the middle of a TCP connection, go back until you get all the packets that belong to that connection (to the SYN) and go forward from there. Won't work for UDP, I suppose. 



	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.
Surely a counter could be kept. Unless I'm misunderstanding what you're saying. 


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.
I don't know enough about how the filters work to comment. I also don't mean to imply that any of the changes would be trivial. I'm used to mostly simple filters, so I'm sure I don't appreciate all the problems involved. I appreciate you taking the time to explain some of the issues to me. 

						BB