(I thought I had sent this, but never did) As to the database etc issue, I think we need to look at something that merges the plugins with an event-like strategy. Basically, XML or csv is one flame war, and no set of fixed tables is ever going to satisfy everyone. etc. etc.
So my thought is this: * At various points in the code (session init, session term, new host, host purge, etc.) we call an event switchboard routine with all the appropriate data passed to it. We do this via a trivial #define macro, so the code impact is trivial - the call is something like this: #define ntopevent (eNumber, p1, p2, p3) ntop_event_call(eNumber, p1, p2, p3) which is ntop_event_call(int eNumber, (void *) p1, (void *) p2, (void *) p3) (i.e. we coerce the parameters to (void*) - the switchboard knows what it's expecting and so it casts back...) In fact, if you don't want events (--disable-events), the macro becomes a no-op and there is ZERO impact. * The switchboard invokes zero...n plugins which have registered themselves as handlers for event(s). A bitmap per plugin with the lookup on eNumber makes this relatively inexpensive. * We chain together these plugins, so that if there is more than one that fits the signature, they all get a chance at the "event". plugin.c simply needs to call everybody that fits the signature with the data. * Each plugin has a big switch statement which invokes a series of functions. In the skeleton we distribute, these do nothing. But it becomes trivial to write a SQL insert, or a flat file log or whatever. * Probably also need a timed call into each plugin (every 5..100 seconds). For housekeeping, etc. * Then, we rewritte the netflow and sflow sender routines into this model, and sql/mysql (i.e. the difference between the two becomes moot). * We can keep the present netflow/sflow parameter model for future "event" plugins. -----Burton -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Luca Deri Sent: Monday, July 22, 2002 10:57 AM To: ntop Mailing List Subject: [Ntop] ntop DB support Hi all, I have added a new directory named NetFlow that contains a client for storing ntop-generated flows into a DB (in this case MySQL). As I have said in past mails, I plan to remove database support from ntop. This is because: - ntop is too fat - database support (as of today) is suboptimal - ntop must export information in a better way. I'm not sure whether NetFlow is the way to go: hovewer is a step ahead. As the DB support in ntop needs to be redesigned I would like to know whether: - there are volunteers out there for coding it - you have some proposals. Cheers, Luca -- Luca Deri <[EMAIL PROTECTED]> _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop _______________________________________________ Ntop mailing list [EMAIL PROTECTED] http://lists.ntop.org/mailman/listinfo/ntop
