Citeren Stuart D Gathman <[email protected]>:
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) _______________________________________________ Nut-upsdev mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
