thought:
NSCA is currently on protocol revision 2. The packet itself indicates =20=
which protocol revision it is in, if I remember correctly. Why not =20
simply create a revision 3, and patch send_nsca and nsca, including =20
their corresponding nsca.cfg/send_nsca.cfg files to be capable of =20
utilizing packet structure revision 3? On the NSCA side, you can make =20=
it compatible with both versions 2 and 3, and obviously on the =20
send_nsca side you could do the same, just selecting which version to =20=
use in the send_nsca.cfg file.
In this way, you would be making a lasting contribution to the =20
existing code base (which, by the way is stable and is used all over =20
the place), rather than creating a one-off in perl, which has some =20
disadvantages when dealing with large configurations.
I am not trying to dissuade you from your course, but rather make a =20
case for another possible direction. Consider a setup that has 500 =20
hosts all using passive service checks with NSCA. Would a Perl NSCA be =20=
capable of handling the load?
By the way, I am not uninformed on this topic. In the past 2 years I =20
have written an NSCA replacement (NSCAFE) =
[http://www.monitoringexchange.org/cgi-b ... 2F2349.ht=
ml;d=3D1=20
] in Java, and another extremely high-performance one in C as an =20
event broker module (BRONX) =
[http://archive.groundworkopensource.com ... unk/bronx=
/=20
]
Daniel.
On Aug 25, 2009, at 3:36 PM, Jose Luis Martinez wrote:
> D. Emmanuel Feinsmith escribi=F3:
>> 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 =20
> "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-Ser ... Server.pod
> - I hope Perl will let us prototype more functionalities with less =20=
> 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 =20
> 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 =20
> bad
>
> Finally, I understand some of these features have been long awaited, =20=
> but
> no one has developed them (the last changelog entries for NSCA are =20
> 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 =20=
> it
> open to the community would be more productive
>
> Cheers,
>
> Jose Luis Martinez
> [email protected]
>
> =
--------------------------------------------------------------------------=
----
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 =20=
> 30-Day
> trial. Simplify your report design, integration and deployment - and =20=
> 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
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]