Time stamps in argus records

[Carter Bullard]

Hey Russell,
   So your mail enticed me to double check on the
raconnections.c that is in the current 1.8 tarfile, and
I need to replace it with its the current version.  Minor bug
fix that makes it useable.

   NO, you can specify multiple source files on the command
line of most argus clients, by using multiple -r options.  So
spanning multiple files with raconnections() is a no brainer. 
What I do is use ra() like this:

   ra -r file1 -r file2 -r file3 -r file4 -w - | raconnections -w - | ra
-unc

   which does pretty good.  Any of the clients support their
own filters, so you have a pretty flexible mechanism.

Carter

> -----Original Message-----
> From: Russell Fulton [mailto:r.fulton at auckland.ac.nz]
> Sent: Thursday, September 23, 1999 5:16 PM
> To: argus at lists.andrew.cmu.edu
> Subject: Re: RE: Time stamps in argus records
> 
> 
> 
> On Thu, 23 Sep 1999 08:23:00 -0700 Carter Bullard 
> <cbullard at nortelnetworks.com> wrote:
> 
> > Hey Russell,
> >    Combining multiple Argus records that belong to the same flow
> > is done with raconnections().  Feed a days worth of  argus records
> > into raconnections() and you should get single records for single
> > connections with the start and last timestamps correct.
> > 
> 
> Right, I had forgotten raconnections! There is still one problem I 
> think, and that is that my data is stored in hourly files and if I 
> remember correctly none of the clients will read multiple files.
> 
> I know we have had this discussion before and I recognize that there 
> will be problems if users feed files to client out of order but I 
> strongly feel that the utility of having the data stored in managable 
> chunks (eg. hourly) while retaining the ability to do long running 
> analysis far out wieghs any problems.
> 
> What I suggest is a new flag ( -R ?) which gives the name of a file 
> containing the list of input files.  I propose this rather than the 
> usual list of filenames on the command line for two reasons: 
> firstly we 
> already have an undelimited string of tokens in the filter 
> and secondly 
> I want more flexibility in listing files than the shell globbing 
> permits.
> 
> I will have a look at the client code today and see if I can 
> figure out 
> what is involved.
> 
> Cheers, Russell.
> 
>