radium?

[Carter Bullard]

Hey Peter,
Yes, that would be the architecture I would suggest.  Three reasons why
(assuming we get the bug out):
    1. radium provides better reliability to the remote probes.
          if an argus goes away, radium is suppose to retry the
          connection, every x seconds, to get the source back on line.
          while its doing that, it will maintain the connections that  
any
          ra* programs may have to it, so client programs don't have
          to be restarted if the argus goes away.

    2. writing out to a socket is less expensive for argus than writing
        to a file, thus allowing argus to get back to tracking packets.

    3. radium provides multiple access to the data stream.

I would go further, so that I would have a rasplit()/rastream()
connecting to radium, to establish the archive, rather than
grabbing the file and processing it periodically.  This results
in records being in the archive almost in real-time, so if you
want to go get the records, you don't worry about "is it in the
collection file" or " did it get processed and is in the archive".

so

    argus --------+
                  |
    argus ---- radium --> rasplit --> archive
                  |
    argus --------+


The radium can be on the same machine, or on a remote
machine, or both.

    argus --------+
                  |
    argus ---- radium  -->  radium --> rasplit --> archive
                  |
    argus --------+


Lot of parts, but if it works out well, we can merge
the radium/rasplit function into one single program.

Carter



On Jun 18, 2007, at 3:08 PM, Peter Van Epp wrote:

> 	Is it a correct assumption that I should be using an argus on each
> interface of a FDX link and feeding both the results in to radium  
> to write
> the log file on the remote host?
> 	Currently I have argus reading two interfaces and writing to a  
> socket:
>
> argus -dJR -P 560 -i eth0 -i eth1 -U 512 -m   -> ra -S host:560 -w out
>
> is
>
> argus -JR -P 560 -i eth0  -U 512 -m
> 					-> radium -S host:560 -S host:561 -w out
> argus -JR -P 561 -i eth1  -U 512 -m
>
> the preferred method?
>
> Peter Van Epp / Operations and Technical Support
> Simon Fraser University, Burnaby, B.C. Canada
>

Carter Bullard
CEO/President
QoSient, LLC
150 E. 57th Street Suite 12D
New York, New York 10022

+1 212 588-9133 Phone
+1 212 588-9134 Fax


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20070618/4ed2fce2/attachment.html>