[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