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

[Charles Lepple]

On Jun 29, 2011, at 3:29 AM, Arjen de Korte wrote:

> Citeren Stuart D Gathman <stuart at bmsi.com>:
>
>> Your test is with localhost - so any non-existent socket would get  
>> immediately rejected.  The nut scanner has to deal with hosts on  
>> the network.  If they send an ICMP reject, then there is no need  
>> for a timeout.  But it is very common for a host to simply "eat"  
>> attempts to connect to a port not allowed in their firewall.  So  
>> nut scanner needs a non-blocking version of upscli_connect.
>
> This probably won't scale very well. On a small /24 subnet this  
> might be feasible, but as soon as you hit /20 (or even larger) this  
> is impractical (let alone what will happen if you happen to use a / 
> 64 IPv6).

To be honest, I'm not terribly excited about the notion of a NUT  
scanner - specialized tools like nmap can do a much better job at port  
scanning, and corporate network security teams may get upset at seeing  
that sort of activity on infrastructure machines. But it's a separate  
tool that gets invoked manually, so I don't want to get in the way of  
development.

> For the purpose of auto-detecting servers I'd propose to resurrect  
> the UDP code and broadcast the servers presence once every 10  
> seconds or so. Yes, this has its drawbacks too (to make sure the  
> broadcasts reach the potential clients), but this has the advantage  
> to be setup by a (knowledgeable) network administrator instead of an  
> aspiring NUT user that has no clue where the server (s)he needs to  
> connect to is located.

On the other hand, broadcasting presence is the kind of feature that  
would need to be enabled manually in order to be useful, and if  
enabled by default, would be a nuisance.

I wouldn't want NUT to get a reputation for being as noisy on the  
network as a protocol like NMB or even the Cisco Discovery Protocol.  
This is where a protocol like Multicast DNS (mDNS) really shines. When  
a service comes up, the UDP DNS message is sent out on the link-local  
multicast group, and retransmissions are sent with an exponential  
backoff time. Clients can also initiate a query, and the idea is that  
queries would be managed by a long-lived daemon that caches query  
responses beyond the lifetime of the clients requesting information.

This has come up a few times before - the usual mDNS implementation on  
*nix system is Avahi, and in the simplest case, NUT only needs to  
provide a static .service file to the Avahi daemon which says "contact  
upsd on this port at this hostname". It's just the usual "round tuit"  
shortage...

> Furthermore I don't think it is a good idea to add timeouts to the  
> existing upscli_connect and/or make it non-blocking. What we're  
> looking for in nut-scanner is something that quickly probes a large  
> number of hosts for the presence of a server and only then  
> initializes a connection. So preferably we would like to split the  
> connection of the socket and the initialization of the protocol.

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?