On Mon, 13 Sep 1999, Guy Harris wrote:
> What sort of summary graphs are you thinking of doing? Summaries as in
> "28% of the traffic is HTTP, 17% is FTP, 42% is SMB, ..."?
Note: these are all intended to be Real-Time graphs. I intend to
use every item listed below in Synchronous mode. There will probably be
stuff in there so it can be used on a file w/o choking the processor, but
that's a secondary goal. The primary goal is to make these work
/efficiently/ in sync mode (because that's what we need here).
I intend to add several types of graphs. One of the graphs will be
a pie chart listing the things you note above. Another will be a histogram
with basically the same info. A third will be one I saw on a windoze proggy
and liked: a circle with evenly spread points, each corresponding to an IP,
and lines connecting them (I intend to extend upon this by adding
"intensity" to it -- brighter/thicker means more traffic). Possibly a
fourth showing the same stuff as the third in a different way.
Furthermore, I intend to create generic pie-graph, histogram, and
cross-graph functions, then layer the TCP/UDP src/dest and TCP/UDP port on
top of that (so it can be later used for... whatever anyone wants). This
modularity is typical of code I write (in fact, I sometimes take that
modularity to extremes... but I'll try not to go too extreme in this case
;-).
And since work is paying me to do this, I should have preliminary
code in a week or two. I'll probably spend the rest of this week and most
of next week analyzing the current code and drawing up a detailed structure
(req.s specs, req.s docs, DFD/function-link-tree, etc.). The following
week[end] (20th - 25th) will be preliminary code. If I've properly planned
beforehand, I should be able to get at least one or two of those working
that weekend.
As with all project times, a good estimate is to double it and add
10% (at least, that's my rule of thumb ;-). This "good" estimate puts
functional code somewhere in mid-October. But I'm aiming for semi-
functional code around Sep. 25th.
> > Is anyone already working on this?
>
> Not that I know of; people have talked about it, but I don't know of
> anybody working on it.
Which means I'll be doing it on my own. I love doing this stuff, I
just prefer to be part of a small group ;-).
Oh well, it's got to get done. If I have to do it myself, I'll do
it myself.
> > From my basic glance through the code, it /appears/ that the
> > protocol tree just contains strings. Is this actually the case?
>
> No. Each node in the protocol tree contains a pointer to a "field_info"
> structure, which contains, among other things:
>
> 1) a pointer to a "header_field_info" structure, which contains,
> among other things, a field type;
>
> 2) a union, "value", which contains a value appropriate for that
> field type.
>
> Many entries in the protocol tree are "anonymous" entries, containing
> just a string; however, if a protocol has registered a particular field,
> it can put in an entry corresponding to that field, which could have,
> say, a numeric value.
The things I need right now are TCP [and UDP] src/dest/port. I
think all of these are registered. UDP is not a priority, so if its
relevant info is not registered, I can contemplate that later.
But if it's field-info and I can read an integer from it, it's
perfect. :-)
> > Where in the code should I look for details?
>
> "proto.c" and "proto.h", for starters.
I've skimmed through those already; I suppose it's now time to do a
thorough analysis.
In particular, I need to know the details of how to dissect an
already-built protocol tree (specifically pulling that tcp info out of it).
