Argus Printf Statement

[Chas DiFatta]

Carter writes,

>    It seems that an Argus-1.0 question should be asked
> again, and that is what should the default ra() ASCII
> string be?  We all thought hard to get a default 80
> character output string that looked OK and had what
> was considered useful information.  And we introduced
> the -W option for when there wasn't an 80 character
> limit for the output device.

Maybe I'm a corner case, but I wouldn't place a priority
on trying to fit the default output into 80 characters.
Most of the time when I'm using xterm which is well over
80 chars' I use the -c option of ra which obviously
blows the 80 char limit.  I'd vote to extend the default
real estate.

A long term thought that may be a big effort is to consider
a set of formatted fields like date(1) for those who wish
to roll their own.  I.e.

	%S - source address
	%D - destination address
	%s - source port
	%d - dest port
	%_ - delimiter

ra -nS localhost -Z %S%_%s_%D_%d
128.1.1.1_2358_128.1.1.2_80

I wouldn't do this as an initial effort though.

	...cd

> -----Original Message-----
> From: owner-argus at lists.andrew.cmu.edu
> [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Carter Bullard
> Sent: Monday, July 17, 2000 4:26 AM
> To: 'Russell Fulton'; argus at lists.andrew.cmu.edu
> Subject: RE: Argus Printf Statement
> 
> 
> Hey Russell,
>    Yes, tabs seem like they have more utility as
> an alternate default delimiter.  Getting the data
> into Excel, for example, is a lot easier if you've
> got tab or comma delimited fields.
> 
>    We'll want to do this in addition to the argprintf()
> type approach, which will give us a lot of flexibility
> to specify whatever delimiter you want.  The task of
> defining the syntax is the hard part, and so we'll need
> to start that soon. Anyone want to take a first stab?
> 
>    It seems that an Argus-1.0 question should be asked
> again, and that is what should the default ra() ASCII
> string be?  We all thought hard to get a default 80
> character output string that looked OK and had what
> was considered useful information.  And we introduced
> the -W option for when there wasn't an 80 character
> limit for the output device.
> 
>    This is still very important!  Do we want to
> modify the existing default output strings?
> 
> Carter
> 
> -----Original Message-----
> From: owner-argus at lists.andrew.cmu.edu
> [mailto:owner-argus at lists.andrew.cmu.edu]On Behalf Of Russell Fulton
> Sent: Monday, July 17, 2000 1:36 AM
> To: argus at lists.andrew.cmu.edu
> Subject: Re: Argus Printf Statement
> 
> 
> FIrstly sorry for the silence when this first came up -- I have been 
> off the net for a few days....
> 
> 
> On Wed, 12 Jul 2000 08:03:15 -0400 Carter Bullard <carter at qosient.com> 
> wrote:
> 
> > 
> > This I believe would be a huge thing to do, and I would like to
> > get some opinions on how this could work.  Now I don't have any
> > Perl experience, so all my examples will be C oriented.
> > 
> > I can see providing an argprintf() function that mimics sprintf():
> > 
> >    argprintf((char *)buf, (char *)formatstr, (ArgusStruct *) arg)
> > 
> > and the formatstr can have a syntax very much like printf() and
> > strftime().  A first thought, we could come up with a syntax
> > that allows us to extend the normal printf() and strftime()
> > formats with Argus data identifer tags.  This would allow a
> > preprocessor to be able to construct real sprintf() and
> > strftime() calls based on our syntax.
> > 
> > We've got to be able to specify source vs. destination for metrics
> > and flow identifiers, so a %s.X and a %d.Y type of qualifier may
> > be all that is needed.  For time we've got start and stop time
> > values and their formats to consider.
> 
> Yep, that basically what I had in mind.  In particular I wanted to be 
> able to supply the format string to whatever replaces ra...
> 
> That said, I could live with the simple delimited lists output that 
> others have suggested.  One point though is how do we get at data which 
> isnt in the default displays? eg. time to live
> 
> One motivation for specifying the formatting is that formatting seems 
> to be a major part of the cpu overhead of ra.  (i.e. ra spends a lot of 
> time formatting output records)  So I thought that it might spead it up 
> by only getting the data formatted that I wanted.  This isnt a very big 
> deal though and may not be worth the effort.
> 
> As for what delimiter to use I prefer tabs since they won't occur in 
> any legitimate data.  '-' are used in the current default format for 
> the reset/direction symbols.  That said I really don't care so long as 
> we can be sure it won't someday pop up in a data field.
> 
> Cheers, Russell
> 
>