Welcome, Guest. Please login or register.

Author Topic: Concurrent Discovery  (Read 14117 times)

oxo

  • Guest
Re: Concurrent Discovery
« Reply #15 on: February 07, 2009, 12:00:49 AM »
Here is my 10 cents ...

I have been using nedi since about 2003 cos I hate making GUI's: last year I went to ver 1.0
The delay in 0.8 -> 1.0 was I needed an infrastructure:
  • 3 companies with 2 servers per company (nedi, rancid, cacti, php-syslog)
    2 central data servers
    • MySQL with circular replication
      SVN for quick push of program alterations to the 6 servers (and other things)
I spent a bit of time with cacti to get automatic graph  (NeDi returned to the Cacti scene with auto cacti)

From the end of december, I began to gear up to (once again) try and see if NeDi could 5 min RRD
- there was a mock up of a solution for about 2 years ago while I was away, but it wasn't good enough (didn't use NeDi routines enough).

NeDi will soon be writting Device Table etc as soon as a device is done and not "all at once"
- this removes a lot of work for me.

I have now played about with pre-beta-release code, and now I am sure that:
- NeDi will be able (at some near future stage) to do RRD's within 5 min

Some bullets for what I think that a future version of nedi could contain:
  • No cronjob: starting a race every 5 min is bad->demonize and spread the workload of a known number of devices over 5 min
  • non-blocking snmp: helps a "state machine" type flow
  • threads: one for moni, one for rrd, one for discovery, one for ? started from nedi.pl using the same %dev but using the data as $devRef =$dev{na} giving  $devRef->{cm} type usage of the data and calls like &Identify($devRef);
  • continued use of def files: which can be expanded to include information about if the device type is sensitive to being polled to much ...

(Don't get me started on multi-NeDi machines ...)

Can NeDi's father do it?
- definitly but time, time, time.

Can we as the million monkeys help him?
- definitly...

I have some ideas I want to work out in the forum.
The code can be worked so that, if the monkeys can type, a general snmp non blocking code with threads could be made and get the specialized NeDi code worked in.
NeDi code is great for cut and paste ( I hate writing something from scratch)

It is important for NeDi's father that  non-thread, non-non-blocking nedi.pl still exists; this should be possible inside the same code base without to many if/else.

NeDi's father is working hard: so keep using his wish list and the PayPal Icon
- it doesn't get the bread on the table, but it helps with a bit of butter.


« Last Edit: February 07, 2009, 12:17:11 AM by oxo »

duanew

  • Guest
Re: Concurrent Discovery
« Reply #16 on: February 08, 2009, 01:11:21 PM »
Tx for the info. I'm gearing the next 1.0.x release towards parallel discovery. But to actually implement it will require many different approaches (on link and node handling). I'm thinking of dropping MAC forwarding tables alltogether and use more efficient mechanisms to assign nodes. I just don't know when I'll find the time for this...

We have a new server (Quad Xeon) and I would like to try your latest code.  Is it in SVN?

I can see 1.0.w-1 and 2.  I haven't used SVN before, how do I get the code out?

oxo

  • Guest
Re: Concurrent Discovery
« Reply #17 on: February 11, 2009, 12:04:51 AM »
(Please note that there is a usefull candidate for rrd graphs @ http://forum.nedi.ch/index.php?topic=433.msg1704#msg1704)