From: Jose L. M. <jlm...@ca...> - 2009-08-25 19:36:51
|
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 jlm...@ca... |