NSCA enhancements for larger output
Andreas Ericsson
ae at op5.se
Thu Jan 22 16:14:11 CET 2009
Ton Voon wrote:
> Hi!
>
> I'm looking into increasing the size of the NSCA information. At the
> moment, the plugin_output part is, by default, 512 bytes long and with
> Nagios 3 it makes sense to try and increase that amount (though I'm
> not looking to include linefeeds, just increased plugin and
> performance data).
>
> I want to do it by updating NSCA, preferably with backwards
> compatibility, rather than switch to an entirely new method.
>
> The technique that we used for increasing NRPE's output while keeping
> backwards compatibility (http://opsview-blog.opsera.com/dotorg/2008/08/enhancing-nrpe.html
> ) basically works by sending a special flag to say that more data is
> coming. However, this won't work with NSCA because we use nsca with --
> single and, with multiple send_nscas running at the same time, packets
> could get intermingled.
>
That really shouldn't be a problem with tcp, unless ncsa is using raw
sockets and implementing tcp (badly) itself.
> So I'm wondering if anyone has good ideas on how this could work? I
> think that a variable packet size is probably best (with the minimum
> as NSCA currently sends, for compatibility, and a maximum at compile
> time) with that single packet holding all the plugin check
> information. However, I don't have much C network coding experience.
> Are there are good examples to work from? Will this technique even
> work (will NSCA's encryption change packet sizes?).
>
Depending on the encryption scheme used, it may alter the packet size.
Any block-based cipher will pad the block to a fixed size. The xor
"encryption" will not.
Basically, any strong encryption method will always pad the resulting
cipher-block to a size that's (normally) a power of 2.
--
Andreas Ericsson andreas.ericsson at op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
More information about the Developers
mailing list