printf(3)ing flow variables (was "Re: Format strings.")

[Dave Plonka]

Hi Carter,

On Thu, Feb 07, 2002 at 12:37:16PM -0500, Carter Bullard wrote:
> Hey Dave,
>    Cflow could be useful if it printed out all the information
> that is available from argus data.

I hope you agree that its useful now (because it makes FlowScan compatible
with Argus), but I know what you mean - it "could be *more* useful". ;^)

> Are you interested in making additions?

Yes.

Currently Cflow supports just a subset of the information that argus
apparently provides.  In the Cflow package the per-flow data items are
called "flow variables" or "flowvars".  I'm not an expert on Argus, so
I don't even know what it's missing - I just added the stuff I needed.
(That's always a safe bet when your development time is limited...)

To support flow-source-specific flow variables, we should probably
create another class such as Cflow::Argus.  I'm considering asking the
perl powers-that-be where such things would properly fit into the perl
module namespace.  They don't like you to just plunk things down in the
Net tree for instance, which I discussed at some length with them when
I released Net::Patricia.

Anyway, if folks have suggestions on a coherent Object-Oriented Perl
way to extend the Cflow API to handle flow-source-specific extensions
please let me know and perhaps we can cooperate to prototype it.
This will also help solve a problem for reading flow-tools files
when NetFlow aggregation is used.

Patches for Argus-specific changes are welcome but I'd like any changes
to meet these guidelines:

1) don't degrade performance when Cflow is used with other flow-sources
   (this should be easy to avoid, since the code switches into different
   sections for different flow-sources)
2) don't pollute the namespace (i.e. perhaps the user will have to
   request to import ":argusflowvars" or something, like one currently
   imports ":flowvars")
3) preserve the current unidirectional flow API as the default behavior
   (I'm willing th explore the potential benefits of it having a "bidir"
   mode.)

Let me know if that doesn't seem reasonable...

Dave

-- 
plonka at doit.wisc.edu  http://net.doit.wisc.edu/~plonka  ARS:N9HZF  Madison, WI