Argus client: rainv.c

[Carter Bullard]

Hey Marc-Andre,
   If you use the "client library" that is built
from the ./common code directory, then the Argus
records are normalized automatically for you.
So that should not be a problem.

   We'll do whatever you are comfortable with.

Hope all is well,

Carter

-----Original Message-----
From: Marc-Andre Funk [mailto:mfunk at kabel.de]
Sent: Tuesday, March 02, 1999 4:33 PM
To: Carter Bullard
Subject: Re: Argus client: rainv.c


Hi Carter!

Thanks for the quick answer. I just want to make the comment from
the program header (which I missed in the last mail), that
I could not spent the time to test the code in file reading mode 
and on other systems than Linux. I.e. there most likely will be
problems on machines with other byte ordering, because I did not
fully analyze the normalizing mechanisms in the argus frame.
Therefore it might be a bit early to include it in the distribution.
Unfortunatelly I also wil not this timne in the next weeks, so that I
thought it would be a good idea just to send you the code so that is
not totally lost. Maybe it would be a good idea to forward the code
to the argus list, but right now I would not even have the time to deal
with the generated thread - so feel free to forward it yourself for
further development.
A small man page should be quickly generated by cut and past out of
the file header. 

Cheers,
          //MAF


Carter Bullard wrote:
> 
> Hey Marc-Andre,
> 
> Thanks for the sample!!!  We will include
> it, without modification and full credit given,
> in the ./contrib section of the 1.8 release, which
> should come out soon.   If you have a man page or
> any other supporting text that you would like to
> add, please feel free to send that as well.
> 
> A few comments.  The argument handling strategy
> actually does work, as it was a part of some of the
> early packages.  I believe, however, that we may have
> taken it out, because it was somewhat tricky
> to use, and even harder to explain.  I'll look
> into redoing it.
> 
> Yes, we have fixed the select timer issues,
> and they will be in the 1.8 package.
> 
> And with regard to the reading strategy for
> the clients.  Yes, there are issues with regard
> to partial reads that can be annoying, and
> we dealt with those a great deal between 1.4
> and 1.5.  Since we are writing and reading rather
> small blocks, you don't see the problem but in
> rather rare situations.  There are actually a lot
> of potential problems with the simple approach
> that we've taken in Argus.  The trick is that we
> don't waste a lot of time on the writing side
> for the socket based strategy.
> 
> If reliable Argus record delivery is critical,
> I/we recommend using the file based approach and
> then implementing a distributor that gets the
> records where you want them to go, using the file
> as a repository until your happy.
> 
> Thanks greatly again for your sample code,
> and stay in touch,
> 
> Carter
> 
> -----Original Message-----
> From: Marc-Andre Funk [mailto:mfunk at kabel.de]
> Sent: Monday, March 01, 1999 1:48 PM
> To: argus at sei.cmu.edu
> Subject: Argus client: rainv.c
> 
> Hello Argus Team!
> 
> Since I find argus to be a very useful tool for network
> monitoring and diagnosis, I'm a bit astonished, that there are
> no more clients available.
> Please find enclosed the source of a small client, which is primarily
> intended to run in client mode and to monitor the network inventory
> (i.e. which IP's are seen and what HW addresses do they have and did
> the correlation between both change).
> The description of the usage of the tool is part of the file header.
> Feel free to use the source as an starting point for other
> functionality but please reference my name as one of the authors.
> 
> I have a few comments about the argus framework, which probably
> should be solved since they may be one reason that there are no
> more clients:
> 
>  1. The argument handling is not implemented. This is a very crude
>     restriction to a UNIX tool...
>  2. There is a flaw in the main loop of the client - the time out
>     variable might be modified by select, so it has to be reinitialized
>     with each loop - else wise it will shrink and the loop will impose
>     a big load to the system.
>  3. When reading from a stream it is not necessarily true, that all
>     data comes in one package. I.e. if one simply tests if the
>     received data is fitting the record size one might loose records
>     which are fragmented and (much worse) might get out of sync with
>     the data stream. Instead one has to collect data until the record
>     buffer is filled, which might involve multiple reads.
> 
> Kind regards,
>                //MAF
> 

-- 
Dr. Marc-Andre Funk
Kabel New Media GmbH
http://www.kabel.de/

Schulterblatt 58
20357 Hamburg
Germany
fon: 49.40.43.29.69-605
fax: 49.40.43.29.69-90
e-mail: mfunk at kabel.de