<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 22 Jan 2009, at 15:14, Andreas Ericsson wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Ton Voon wrote:<br><blockquote type="cite"><span class="Apple-style-span" style="-webkit-text-stroke-width: -1; ">The technique that we used for increasing NRPE's output while keeping </span></blockquote><blockquote type="cite">backwards compatibility (<a href="http://opsview-blog.opsera.com/dotorg/2008/08/enhancing-nrpe.html">http://opsview-blog.opsera.com/dotorg/2008/08/enhancing-nrpe.html</a> <br></blockquote><blockquote type="cite">) basically works by sending a special flag to say that more data is <br></blockquote><blockquote type="cite">coming. However, this won't work with NSCA because we use nsca with -- <br></blockquote><blockquote type="cite">single and, with multiple send_nscas running at the same time, packets <br></blockquote><blockquote type="cite">could get intermingled.<br></blockquote><blockquote type="cite"><br></blockquote><br>That really shouldn't be a problem with tcp, unless ncsa is using raw<br>sockets and implementing tcp (badly) itself.</div></blockquote><div><br></div>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.</div><div><br><blockquote type="cite"><div><blockquote type="cite">So I'm wondering if anyone has good ideas on how this could work? I <br></blockquote><blockquote type="cite">think that a variable packet size is probably best (with the minimum <br></blockquote><blockquote type="cite">as NSCA currently sends, for compatibility, and a maximum at compile <br></blockquote><blockquote type="cite">time) with that single packet holding all the plugin check <br></blockquote><blockquote type="cite">information. However, I don't have much C network coding experience. <br></blockquote><blockquote type="cite">Are there are good examples to work from? Will this technique even <br></blockquote><blockquote type="cite">work (will NSCA's encryption change packet sizes?).<br></blockquote><blockquote type="cite"><br></blockquote><br>Depending on the encryption scheme used, it may alter the packet size.<br>Any block-based cipher will pad the block to a fixed size. The xor<br>"encryption" will not.<br><br>Basically, any strong encryption method will always pad the resulting<br>cipher-block to a size that's (normally) a power of 2.</div></blockquote><div><br></div>I wonder how this is working then? We only use DES encryption, but there are other choices.</div><div><br></div><div>In send_nsca.c, it sends sizeof(send_packet) which is always 700 bytes - there's no checking for the size.</div><div><br></div><div>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.</div><div><br></div><div>Ton</div><div><br></div></body></html>