NSCA enhancements for larger output

[Ton Voon]

On 22 Jan 2009, at 15:14, Andreas Ericsson wrote:

> Ton Voon wrote:
>> 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.

I've updated the tests scripts that send results all at the same time,  
and there is no merging of results which says that the socket data  
receiving is working correctly.

>> 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.

I wonder how this is working then? We only use DES encryption, but  
there are other choices.

In send_nsca.c, it sends sizeof(send_packet) which is always 700 bytes  
- there's no checking for the size.

Hmmm. Looking in utils.c, it appears in encrypt_buffer, it is  
encrypting a single byte at a time, so that means there will be no  
padding of the data.

Ton

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20090126/e3925c12/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel