[Nut-upsdev] Changes to upscli_connect

Arjen de Korte nut+devel at de-korte.org
Wed Jun 29 07:29:50 UTC 2011


Citeren Stuart D Gathman <stuart op 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). 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.

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.

Best regards, Arjen
-- 
Please keep list traffic on the list (off-list replies will be rejected)





More information about the Nut-upsdev mailing list