First off, -s has been removed as -s <hashsize>

It's now a (future) flag to turn off promiscuous mode.  That is the code to set it is 
in:

       initialize.c:   980                       myGlobals.disablePromiscuousMode == 1 
? 0 : 1,
             main.c:   452         myGlobals.disablePromiscuousMode = 1;
          globals.h:   105     u_char disablePromiscuousMode;

But that's all.

AFAIK, there is now no limit on hash size growth.  The constant is still defined, but 
it's not used anymore:

             ntop.h:  1311   #define MAX_HASH_SIZE             32768

The code that resizes the hash is this:

          if(!hostFound) {
            int sz;

            list->idx = myGlobals.device[actualDeviceId].actualHashSize;
            if(myGlobals.device[actualDeviceId].actualHashSize < 512)
              myGlobals.device[actualDeviceId].actualHashSize = 512;
            else
              myGlobals.device[actualDeviceId].actualHashSize *= 2; /* Double */
            sz = myGlobals.device[actualDeviceId].actualHashSize*sizeof(struct 
hostTraffic*);
            myGlobals.device[actualDeviceId].hash_hostTraffic = (struct
hostTraffic**)realloc(myGlobals.device[actualDeviceId].hash_hostTraffic, sz);
            memset(&myGlobals.device[actualDeviceId].hash_hostTraffic[list->idx],
                   0, sizeof(struct 
hostTraffic*)*(myGlobals.device[actualDeviceId].actualHashSize-list->idx));
            traceEvent(TRACE_INFO, "Extending hash size [newSize=%d][deviceId=%d]",
                       myGlobals.device[actualDeviceId].actualHashSize,
                       actualDeviceId);
          } else

The only limit is available memory.  Remember that the realloc will - under the covers 
- require enough memory for the new size
(rounded to a full page) + the original size (it does a malloc, copy, free set 
internally).

Now there is a report that the realloc can fail and cause all kinds of horrible 
problems (and I agree that should be tested for),
but if you have enough ram, you should be able to grow beyond 32K...

You can TRY the attached patch.  It's under development, and will ONLY report the 
error if the realloc fails!!

(All greps are from 2.0.99 ntop-02-04-27.tgz)

-----Burton


-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Michael Baird
Sent: Monday, April 29, 2002 10:35 AM
To: [EMAIL PROTECTED]
Subject: [Ntop] Ntop 29-4-02 snapshot


I'm using ntop with the netflow plugin, and it's finally starting to
look promising, except for a couple of issues.  It now compiles
properly, runs properly, and works properly, however it doesn't clear
the hash in RAM, my understanding was at 32768 it should clear the hash
and start over, is this incorrect, or do I need to run it with some
extra arguments, I tried the -S 1 and -S 2 options, neither work with
the netflow plugin, -S 0 does. I'm currently using /usr/local/bin/ntop
-u root -d as my only arguments, I've tried -s <hashsize> as described
in the FAQ but ntop doesn't pay attention to this either.

Regards
MIKE



_______________________________________________
Ntop mailing list
[EMAIL PROTECTED]
http://listgateway.unipi.it/mailman/listinfo/ntop

Attachment: BMS0064-realloc-hashsize-failure.patch
Description: Binary data

Reply via email to