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