New project announce: NSCA2

Daniel Emmanuel Feinsmith daniel at danielemmanuelfeinsmith.com
Wed Aug 26 15:31:50 CEST 2009


What you say makes sense, however, I would consider the following  
thought:

NSCA is currently on protocol revision 2. The packet itself indicates  
which protocol revision it is in, if I remember correctly. Why not  
simply create a revision 3, and patch send_nsca and nsca, including  
their corresponding nsca.cfg/send_nsca.cfg files to be capable of  
utilizing packet structure revision 3? On the NSCA side, you can make  
it compatible with both versions 2 and 3, and obviously on the  
send_nsca side you could do the same, just selecting which version to  
use in the send_nsca.cfg file.

In this way, you would be making a lasting contribution to the  
existing code base (which, by the way is stable and is used all over  
the place), rather than creating a one-off in perl, which has some  
disadvantages when dealing with large configurations.

I am not trying to dissuade you from your course, but rather make a  
case for another possible direction. Consider a setup that has 500  
hosts all using passive service checks with NSCA. Would a Perl NSCA be  
capable of handling the load?

By the way, I am not uninformed on this topic. In the past 2 years I  
have written an NSCA replacement (NSCAFE) [http://www.monitoringexchange.org/cgi-bin/page.cgi?g=Detailed%2F2349.html;d=1 
]  in Java, and another extremely high-performance one in C as an  
event broker module (BRONX) [http://archive.groundworkopensource.com/groundwork-opensource/trunk/bronx/ 
]

Daniel.

On Aug 25, 2009, at 3:36 PM, Jose Luis Martinez wrote:

> D. Emmanuel Feinsmith escribió:
>> Out of curiosity, based on the changes in your description, why not
>> submit these changes as a patch?
>
>  - Perl is my "native" language, and I can program faster than in C,
> with less errors, and less restrictions.
>
>  - The base class for the server is Net::Server that provides for  
> "free":
>    - configuration file management
>    - different process models: Forked, Preforked, Single, etc (that
> right now nsca would have to handle by itself)
>    - Handling of SIGHUP to reload config
>    - just see:
> http://search.cpan.org/~rhandom/Net-Server-0.97/lib/Net/Server.pod
>  - I hope Perl will let us prototype more functionalities with less  
> pain
>
> note: All of this is not because of Perl itself. I'm sure Python and
> other languages can handle all of this as easily (I don't want to  
> start
> a "best language" flame).
>
>  - if you extend nsca, you have to be backwards compatible, and carry
> some design decisions that would probably be hard to avoid or make the
> code nasty:
>    - when an nsca client connects, the server sends an initial packet,
> with the timestamp the client will send back and the IV to initialize
> encription. This forces one round trip of communication, because the
> client has to wait for the server. NSCA2 aviods this by:
>      - using the timestamp from the client
>      - initializing the IV at the client, and sending the result with
> the IV to the server.
>      - the client just speaks to the server and closes the connection
>  - I consider that reengineering from time to time is not all that  
> bad :)
>
> Finally, I understand some of these features have been long awaited,  
> but
> no one has developed them (the last changelog entries for NSCA are  
> from
> 03/jul/2007, and the last feature is from 06/Apr/2006), so I've had to
> scratch my own itch the way I deemed better, and thought that making  
> it
> open to the community would be more productive ;)
>
> Cheers,
>
> Jose Luis Martinez
> jlmartinez at capside.com
>
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008  
> 30-Day
> trial. Simplify your report design, integration and deployment - and  
> focus on
> what you do best, core application coding. Discover what's new with
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july




More information about the Developers mailing list