<br><div class="gmail_quote">2011/6/29 Charles Lepple <span dir="ltr"><<a href="mailto:clepple@gmail.com">clepple@gmail.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
On Jun 29, 2011, at 3:29 AM, Arjen de Korte wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Citeren Stuart D Gathman <<a href="mailto:stuart@bmsi.com" target="_blank">stuart@bmsi.com</a>>:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
<br>
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).<br>
</blockquote>
<br>
To be honest, I'm not terribly excited about the notion of a NUT scanner</blockquote><div><br>just to disambiguate your words for Fred and others: you were probably referring to nut-scanner discovery NUT hosts with the *old* method.<br>
and not the nut-scanner effort as a whole?!<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"> - 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.<br>
</blockquote><div><br>if only there was a standard tool, where we just have to declare our USB, SNMP, (...) info, I would probably be the first to run that way.<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
<br>
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.<br>
<br>
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.<br>

<br>
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...<br>
</blockquote><div><br>you summed up very well Charles ;-)<br>moreover, the UDP broadcast approach is IPv4 only, and is reinventing the (mDNS) wheel...<br> and that's all we want to avoid.<br><br>I've just committed the Avahi service file to trunk (r3109), since the other approach I've been investigating (avahi-publish call from init script) was causing problems with systemd/upstard and friends<br>
the only drawback I see, WRT upscli_connect(), is the fact that avahi exposure only means that nut is installed, not started...<br><br>note that avahi support still need some completion, for installing the file upon detection of avahi presence...<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>

</blockquote>
<br>
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?<br>
</blockquote></div><br>indeed.<br>as for the compat, IIRC Fred proposed a a new _tryconnect() method, upon which the standard _connect() would be mapped, with no behavior change.<br><br clear="all">cheers,<br>Arno<br><br>