NRPE 3.0? (protocol enhancements)

[Michael Medin]

Hello,

I know this is the wrong list but I am not subscribed to plug-devel and 
figured this could work as well, if not let me know and I shall move 
this to that list instead :)

Since I had gotten some requests for NSClient++ to allow "longer 
payloads" (I added this but it requires a recompile of check_nrpe with 
#define MAX_PACKETBUFFER_LENGTH <bigger value>) I was a bit curious 
about any ideas for a "new" version of NRPE with amongst other things 
variable length payload?

Things I can imagine are;
* variable length payload (ie. negotiations of length)
* authentication (both simple password and certificates/keys)
* multiple queries/multiple results (I know Nagios wont support this out 
of the box but a proxy agent could repackage and upload via NSCA or some 
such, also other monitoring solutions does support and use this)
* TLS support (if nothing else just to make it simpler to negotiate 
encryption/non-encryption)
* encoding/Unicode support (either a tag specifying the incoming 
encoding and(or?) UTF8 support)
* support for the |-char (as of now this is "used and cant be escaped")
* support for "proper" performance data (ie. a separate "channel" for it)
... probably a few other things I cant recall now...

Just a bit curious if there is any interest, I myself am not really much 
of a Unix developer (okey, I admit it, I hate emacs, and doing "longer 
things" in vi is damn tedious) so not that interested to do the "Unix 
client/server" but I would gladly add such support on "my end" (ie. 
windows side).

Anyways, just throwing this out to see if there is any takers...

BTW, there is also a "bug" in the NRPE client/server it "only" reads 
whats in the buffer and never waits for "more data" not much of a 
problem since 1024 chars usually fit inside the buffer, but 
theoretically if there is a hell of a lot of lag it might not, but more 
importantly if you set MAX_PACKETBUFFER_LENGTH to more then around 16k 
you get incomplete payloads.

// Michael Medin

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/