typdef struct {
uint8_t version=3DMYVERSION;
blah blah blah
} service;
Then check what the module returns like:
if((uint8_t)service !=3D MYVERSION) {
moan_and_complain();
kick_module();
}
(Yeah yeah a union would probably be clearer, and there are 50 ways to =
do=20
this, and yes they are all dandy
Its a little hacky, but not too bad.
The biggest concern I have with this model is that a poorly behaved =
module is=20
much more likely to corrupt the core process by doing something evil=20
(unintentionally I'm sure) than in your other model.=20
I'm sort of working on a simular problem and decided to create an API =
that
the "clients" linked to handle the nasty parts for them (so each =
"client"
would be an independent entity/process unless someone wanted to create a
"super server client" that loaded modules). This would have each =
"client"=20
create a shared mem queue (or a sysv queue - haven't fully decided which =
is=20
less evil for this app) and then hand a pointer (literally or not) for =
that=20
off to the "server" and register the events they want dumped into it. =
This=20
would in theory allow me to have multiple pre-forked backend processes=20
handling a single queue if I'm doing something with the data that blocks =
a=20
lot without stacking up a lot of processes or having to fork for each =
event=20
(which can be really bad if you have a lot of events). =20
This is (in essense) very simular to your socket model with the main =
difference
being that I don't care what the clients do (queue's full? Tough, =
message dropped!
although to be polite we might increment a counter they can query). =
They are
completely decoupled from any of the server code (except thier =
interaction via
the well defined API). This puts a little more burden on the module =
writers, but
cleans up the servers interactions (I don't have to worry about timing =
them out,
or other bad things they might do).
> -----Original Message-----
> From: Ethan Galstad [mailto:[email protected]]
> Sent: Thursday, July 31, 2003 10:02 PM
> To: [email protected];
> [email protected]
> Subject: [Nagios-users] Nagios 2.0 Event Broker and DB Support
>=20
>=20
> Sorry for the crosspost, but the nagios-devel list is usually pretty=20
> quiet when I request comments about new features I'm implementing. =20
> This one is bigger than most, so I wanted to reach more people. This=20
> is a bit long, so bear with me...
>=20
> I am almost complete with coding for 2.0. Two big things remain: the=20
> event broker and DB support (which is currently broken).
>=20
> My original intent was to develop the event broker as a separate=20
> application, tying it to Nagios with a unix domain socket. Nagios=20
> would send the event broker information about the everything that was=20
> going on (service checks, downtime, flapping, log entries, etc.). =20
> The event broker would be able to load user-developed modules (object=20
> files) at runtime and pass various types of Nagios data to them for=20
> processing. This is all fine and good. I have a working prototype=20
> of the event broker that does just this and seems to work okay. I=20
> got to thinking that it was rather stupid to develop a separate=20
> application for this when I could simply have Nagios load user-
> developed modules itself. Doing this would give the modules the=20
> benefit of having access to internal Nagios structures and functions=20
> (which is good and bad - see below).
>=20
> Here's an overview of how it would work:
>=20
> - Nagios would load user-specified modules (object files) at startup=20
> using the dlopen() function.
>=20
> - Nagios would call the module's initialization function (the name of=20
> which would be standardized).
>=20
> - The module's init function would register for various types of=20
> Nagios event data (service checks, host checks, log entries, event=20
> handlers, etc.) using callback functions.
>=20
> - When Nagios encounters an event for which a module has registered a=
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]