On Wed, 2011-06-29 at 13:43 +0200, Arjen de Korte wrote: > Citeren Charles Lepple <[email protected]>: > > > I guess I see the scanning code as a stopgap way to contact "legacy" > > servers (or what would be legacy after some discovery protocol like > > mDNS is set up), and either timeouts or non-blocking is just a > > kludge to make that work a little better. And isn't opening a > > non-blocking socket just a way to split socket connection and > > protocol initialization? > > If that's the case, this should be handled by the nut-scanner itself. > For any hosts found to be listening on port 3493 it would then proceed > to use the upscli_connect call to check if it really is a NUT server.
That's a good idea. The only tiny drawback I see is a small duplication of the connect code from upscli_connect to libnutscan, which is not really a concern. > I'm *very* concerned that we're even considering making changes to the > upsclient library for the sake of a tool that is meant for backwards > compatibility. This library should be as light weight as possible. Adding a upscli_tryconnect function to libupsclient is not that so heavy (take a look at the diff I proposed in this thread's first mail), and libupsclient users may be interested in having a connection function with an easily controlled timeout rather than relying on a system's timeout. So maybe it's worth adding such a feature for the rather low footprint. Regards, Fred -- Team Open Source Eaton - http://powerquality.eaton.com -------------------------------------------------------------------------- _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
