> 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-Ser ... 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
[email protected]
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]