Ethereal-dev: Re: [Ethereal-dev] io-stat pretty picture for website

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

From: "Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>
Date: Wed, 20 Nov 2002 19:33:23 +1100
----- Original Message -----
From: "Jason House"
Sent: Wednesday, November 20, 2002 8:46 AM
Subject: Re: [Ethereal-dev] io-stat pretty picture for website


>
>
> Ronnie Sahlberg wrote:
>
> > Right now I am considering adding something to tethereal and ethereal
that
> > mimics the Traffic-Map
>
> > display of  other sniffers.
> > Of course, since it will do this based on ethereal display-filter
matching
> > it will be more powerful and feature rich than anything else in any
other
> > tool. Anything less than that would be a failure.
> >
> > Not really too useful but there are some occasions where something like
this
> > is useful.
> > (to be honest, mainly useful in what I call network-monitors and less so
in
> > protocol-analyzers)
>
> Actually, it could become very useful if the information shown wasn't just
based
> off of traffic loading, but could be based off of any (numerical)
filterable
> field or tap output.  Like what about maximum tcp round trip time or tcp
> retransmission  rate or other things like that?  From the network analysis
> perspective, those are highly useful pieces of information.
>

Interesting idea.
Yes, other criterias than just number of bytes or number of frames would
indeed be very useful.

I will see if it can be made so that the generic case, as I belive to be
either number of frames or bytes,
will not be inefficient. Otherwise it can just be coded as two similar
tools, one being optimized for performance and memory for frames and bytes
only and another more generic one that can do everything.

Let me build a few generations of prototypes so I can see how it would work
and what it will be able to do.


The tcp-retransmission rate would just be to specify the filter
"tcp.analysis.retransmission" and just count number of frames so that one
would not need anything special.
The maximum-round-trip-time would need a special and more generic case, that
one would also be very useful. I will keep that one in mind when prototyping
it.