New project announce: NSCA2

Anthony Montibello amontibello at gmail.com
Thu Aug 27 03:20:44 CEST 2009


Hi,
(I am comenting since I also have traced through the NSCA code)

Currently NSCA is on Packet protocal version 3, (
http://nagios.org/download/addons)
the new project should implement Version 4

I also wrote a Send_NSCA Class in C# on windows.
however C# it is low preformance compared to the C version

In review of the code NSCA protocal basically works like this
Send_Client connects
Server responds with Datestame and buffer size
Client uses this server data to calculate CRC code
Client encrypts then Sends data
Server recieves Data, checks for Valid : Version, CRC, DateTime

I am not sure how easy it would be to make the Send_nsca2 capable of being
backward compatible,
And I would think preformance testing of perl version vrs the curent should
be done.
my C# class has poor preformance so I prefer using other send_nsca over it.

However on the server side, I think it is more practical and a necessity to
maintain compatibility.

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.

Good luck with it, (Hope this helps)
Tony
On Wed, Aug 26, 2009 at 9:31 AM, Daniel Emmanuel Feinsmith <
daniel at danielemmanuelfeinsmith.com> wrote:

> 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
> _______________________________________________
> Nagios-devel mailing list
> Nagios-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/nagios-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20090826/3aec6463/attachment.html>
-------------- next part --------------
------------------------------------------------------------------------------
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
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel


More information about the Developers mailing list