[Nut-upsdev] Changes to upscli_connect (and general discovery)

[Frédéric Bohé]

On Wed, 2011-06-29 at 13:43 +0200, Arjen de Korte wrote:
> Citeren Charles Lepple <clepple at gmail.com>:
> 
> > 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

--------------------------------------------------------------------------