Racluster and the trans field

[Nick Diel]

This is actually a continuation for a bug we discussed a little bit ago and
something CS Lee looked at too.

When you use racluster the trans field did not always add up correctly (it
would be smaller than it should be).  Again I dug into the source code and
think I found the culprit.  We actually set the trans field to 0 in some
cases.  I am not entirely sure why we do this, but it does cause a couple of
problems.  Also what confuses this even more is we now always print a trans
field of 1 or greater (we actually test the trans field, if 0 or smaller we
just print 1).

For the second part of the problem, we do use the value of the trans field
internally to test whether or not to some duration calucations and with the
current logic we do not compute duration on some flows I think we should.

First here is the code in question (from diff):
--- origs/argus_client.c        2009-08-29 11:35:55.000000000 -0600
+++ common/argus_client.c       2009-08-29 11:42:58.000000000 -0600
@@ -4040,15 +4040,6 @@
                      agr->act.minval             = 10000000000.0;
                      agr->idle.minval            = 10000000000.0;

-                     if (parser->ArgusAggregator != NULL) {
-                        value =
parser->ArgusAggregator->RaMetricFetchAlgorithm(retn);
-                        if (ArgusFetchDuration ==
parser->ArgusAggregator->RaMetricFetchAlgorithm) {
-                           if (value == 0)
-                              agr->count = 0;
-                        }
-                     } else
-                        if ((value = ArgusFetchDuration(retn)) == 0)
-                           agr->count = 0;

                      if (agr->count > 0) {
                         agr->act.maxval             = value;

I am not entirely sure what we are testing for so the question is do we need
this code, if so is it correct, and finally should we move the logic so we
are not ever setting the trans field to 0?

Nick
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist1.pair.net/pipermail/argus/attachments/20090829/ca22d964/attachment.html>