<div>Hi,</div>
<div>(I am comenting since I also have traced through the NSCA code)</div>
<div> </div>
<div>Currently NSCA is on Packet protocal version 3, (<a href="http://nagios.org/download/addons">http://nagios.org/download/addons</a>)</div>
<div>the new project should implement Version 4</div>
<div> </div>
<div>I also wrote a Send_NSCA Class in C# on windows.</div>
<div>however C# it is low preformance compared to the C version </div>
<div> </div>
<div>In review of the code NSCA protocal basically works like this </div>
<div>Send_Client connects</div>
<div>Server responds with Datestame and buffer size</div>
<div>Client uses this server data to calculate CRC code </div>
<div>Client encrypts then Sends data</div>
<div>Server recieves Data, checks for Valid : Version, CRC, DateTime </div>
<div> </div>
<div>I am not sure how easy it would be to make the Send_nsca2 capable of being backward compatible,</div>
<div>And I would think preformance testing of perl version vrs the curent should be done.</div>
<div>my C# class has poor preformance so I prefer using other send_nsca over it.</div>
<div> </div>
<div>However on the server side, I think it is more practical and a necessity to maintain compatibility.</div>
<div> </div>
<div>since the Client does not start sending Data till after it recives data, The NSCA (Server side) could test if there is data availible to read, if not - Run version 3 protocal rules otherwise the new algorithm. Sounds simple, but may not be that easy in perl.</div>
<div> </div>
<div>Good luck with it, (Hope this helps)</div>
<div>Tony <br></div>
<div class="gmail_quote">On Wed, Aug 26, 2009 at 9:31 AM, Daniel Emmanuel Feinsmith <span dir="ltr"><<a href="mailto:daniel@danielemmanuelfeinsmith.com">daniel@danielemmanuelfeinsmith.com</a>></span> wrote:<br>
<blockquote style="BORDER-LEFT: #ccc 1px solid; MARGIN: 0px 0px 0px 0.8ex; PADDING-LEFT: 1ex" class="gmail_quote">What you say makes sense, however, I would consider the following<br>thought:<br><br>NSCA is currently on protocol revision 2. The packet itself indicates<br>
which protocol revision it is in, if I remember correctly. Why not<br>simply create a revision 3, and patch send_nsca and nsca, including<br>their corresponding nsca.cfg/send_nsca.cfg files to be capable of<br>utilizing packet structure revision 3? On the NSCA side, you can make<br>
it compatible with both versions 2 and 3, and obviously on the<br>send_nsca side you could do the same, just selecting which version to<br>use in the send_nsca.cfg file.<br><br>In this way, you would be making a lasting contribution to the<br>
existing code base (which, by the way is stable and is used all over<br>the place), rather than creating a one-off in perl, which has some<br>disadvantages when dealing with large configurations.<br><br>I am not trying to dissuade you from your course, but rather make a<br>
case for another possible direction. Consider a setup that has 500<br>hosts all using passive service checks with NSCA. Would a Perl NSCA be<br>capable of handling the load?<br><br>By the way, I am not uninformed on this topic. In the past 2 years I<br>
have written an NSCA replacement (NSCAFE) [<a href="http://www.monitoringexchange.org/cgi-bin/page.cgi?g=Detailed%2F2349.html;d=1" target="_blank">http://www.monitoringexchange.org/cgi-bin/page.cgi?g=Detailed%2F2349.html;d=1</a><br>
] in Java, and another extremely high-performance one in C as an<br>event broker module (BRONX) [<a href="http://archive.groundworkopensource.com/groundwork-opensource/trunk/bronx/" target="_blank">http://archive.groundworkopensource.com/groundwork-opensource/trunk/bronx/</a><br>
]<br><br>Daniel.<br>
<div>
<div></div>
<div class="h5"><br>On Aug 25, 2009, at 3:36 PM, Jose Luis Martinez wrote:<br><br>> D. Emmanuel Feinsmith escribió:<br>>> Out of curiosity, based on the changes in your description, why not<br>>> submit these changes as a patch?<br>
><br>> - Perl is my "native" language, and I can program faster than in C,<br>> with less errors, and less restrictions.<br>><br>> - The base class for the server is Net::Server that provides for<br>
> "free":<br>> - configuration file management<br>> - different process models: Forked, Preforked, Single, etc (that<br>> right now nsca would have to handle by itself)<br>> - Handling of SIGHUP to reload config<br>
> - just see:<br>> <a href="http://search.cpan.org/~rhandom/Net-Server-0.97/lib/Net/Server.pod" target="_blank">http://search.cpan.org/~rhandom/Net-Server-0.97/lib/Net/Server.pod</a><br>> - I hope Perl will let us prototype more functionalities with less<br>
> pain<br>><br>> note: All of this is not because of Perl itself. I'm sure Python and<br>> other languages can handle all of this as easily (I don't want to<br>> start<br>> a "best language" flame).<br>
><br>> - if you extend nsca, you have to be backwards compatible, and carry<br>> some design decisions that would probably be hard to avoid or make the<br>> code nasty:<br>> - when an nsca client connects, the server sends an initial packet,<br>
> with the timestamp the client will send back and the IV to initialize<br>> encription. This forces one round trip of communication, because the<br>> client has to wait for the server. NSCA2 aviods this by:<br>> - using the timestamp from the client<br>
> - initializing the IV at the client, and sending the result with<br>> the IV to the server.<br>> - the client just speaks to the server and closes the connection<br>> - I consider that reengineering from time to time is not all that<br>
> bad :)<br>><br>> Finally, I understand some of these features have been long awaited,<br>> but<br>> no one has developed them (the last changelog entries for NSCA are<br>> from<br>> 03/jul/2007, and the last feature is from 06/Apr/2006), so I've had to<br>
> scratch my own itch the way I deemed better, and thought that making<br>> it<br>> open to the community would be more productive ;)<br>><br>> Cheers,<br>><br>> Jose Luis Martinez<br>> <a href="mailto:jlmartinez@capside.com">jlmartinez@capside.com</a><br>
><br>> ------------------------------------------------------------------------------<br>> Let Crystal Reports handle the reporting - Free Crystal Reports 2008<br>> 30-Day<br>> trial. Simplify your report design, integration and deployment - and<br>
> focus on<br>> what you do best, core application coding. Discover what's new with<br>> Crystal Reports now. <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a><br>> _______________________________________________<br>
> Nagios-devel mailing list<br>> <a href="mailto:Nagios-devel@lists.sourceforge.net">Nagios-devel@lists.sourceforge.net</a><br>> <a href="https://lists.sourceforge.net/lists/listinfo/nagios-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-devel</a><br>
<br><br>------------------------------------------------------------------------------<br>Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day<br>trial. Simplify your report design, integration and deployment - and focus on<br>
what you do best, core application coding. Discover what's new with<br>Crystal Reports now. <a href="http://p.sf.net/sfu/bobj-july" target="_blank">http://p.sf.net/sfu/bobj-july</a><br>_______________________________________________<br>
Nagios-devel mailing list<br><a href="mailto:Nagios-devel@lists.sourceforge.net">Nagios-devel@lists.sourceforge.net</a><br><a href="https://lists.sourceforge.net/lists/listinfo/nagios-devel" target="_blank">https://lists.sourceforge.net/lists/listinfo/nagios-devel</a><br>
</div></div></blockquote></div><br>