On Sun, Feb 25, 2001 at 05:13:28PM -0800, Guy Harris wrote:
> On Sun, Feb 25, 2001 at 05:44:01PM +0100, Pavel Mores wrote:
> > thanks for your comments. Of course, you're right, and I'm willing to work
> > out all the issues you mentioned and then some more but: John McDermott
> > wrote that there had been some discussion whether it was correct to have
> > graphing incorporated in ethereal and you seem to allude to this topic too.
>
> If the graphing code just takes the capture file and processes it,
> producing graphs but not otherwise interacting with the rest of
> Ethereal, I'm not certain whether it'd belong in Ethereal - it's not
> clear what benefit you get from bundling it into Ethereal.
>
> If, however, the graphing code *does* interact with the rest of
> Ethereal, e.g. letting you select a particular conversation and get some
> graph of the behavior of the conversation, I'd see it as possibly
> appropriate for inclusion in Ethereal.
As I mentioned before, I'm quite sure there's a lot to gain by making
graphing code part of ethereal. Even if it didn't, when you use TCP
performance graphs extensively as I do I think you could appreciate
quickness and ease of use that comes with just selecting a segment in
packet list and clicking on a menu entry. Having to process each dump,
each connection with a separate program quickly becomes a drag.
Another thing is that I'm not sure how active development of tcptrace
has been recently. I mean, I didn't notice much progress during the time
I was using it (I have to admit I didn't check it out since I've started
writing my patch).
The graphing code could be made a compile-time option or even separate
ethereal-aware utility program that could be launched from ethereal menu
if you will. But you lose important capabilities by decoupling graphs
from the ethereal. For example, take a look at the feature I already
have, ability to select a segment in packet list by clicking on it in
the graph. I happens all the time during a connection analysis that you
need to examine headers or payload of a segment that looks weird on the
graph. If the graph is linked to ethereal, you just click on the segment
and it gets selected in packet list. Then you're free to immediatelly
use all the wonderful dissecting machinery ethereal already has. On the
other hand, if ethereal and graphing module are separate apps you have
to identify the interesting segment in packet list by other means,
perhaps by searching its sequence number. Or you could add some code to
the graphing app that would display details of the segment in a window
and try to duplicate what ethereal is very good at. Rather clumsy, I
guess. When you need to examine tens of segments out of a 10000 packet
dump it's nearly impossible this way. By the time you search for the
tenth of them you forget what you are doing and why. Believe me, I was
forced to do this before I decided that implementing the ability to
select a packet is a must.
> I'm not likely to look at it until I can at least build it on the flavor
> of UNIX I mainly use at home (FreeBSD) or at work (Solaris) - my to-do
> list on Ethereal is already rather long, as is my to-do list on things
> unrelated to software; perhaps somebody else will take a look at it on
> Linux, but if you want me to look at it, I'd suggest at least addressing
> point 2) and putting in your own declarations for Ethernet, IP, and TCP
> headers.
I understand. I guess it's time to boot my FreeBSD box and make it
compile on it. I'm not sure about Solaris which I don't have access to.
pvl