On 06/28/2011 02:29 PM, Arjen de Korte wrote:
Citeren Frédéric Bohé <[email protected]>:
I am currently working on the nut scanner. For detecting available upsd
on the network, I rely on upscli_connect. The problem with this function
is that it calls a blocking "connect" function.
The upscli_connnect() call should not block. If it does, that is a
problem that needs fixing, rather than adding an timeout. On what kind
of system did you test this? If I attempt to connect upsmon to a
non-existing server socket, the following is shown (-DDD):
0.001902 Trying to connect to UPS [myups@localhost]
0.002667 UPS [myups@localhost]: connect failed: Connection
failure: Network is unreachable
0.002690 do_notify: ntype 0x0005 (COMMBAD)
0.002704 Communications with UPS myups@localhost lost
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.
Instead of a timeout, which is problematic (host may just be slow), I
suggest an actual non-blocking call so that N connects may be started,
and then waited on as a group using select() or os equivalent. The
upscli_connect_start(...) should return a small integer (e.g. file
descriptor), so the app can track the pending connect in a data
structure (along with IP, port, etc), and upscli_connect_wait() will
return the small integer of a pending connect that finished, and
upscli_connect_finish(int) will complete the operation.
There may still be a need for an overall timeout (passed to
upscli_connect_start), since 3 minutes is too long to wait. Something
more like 30 seconds would be appropriate for nut scanner.
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/nut-upsdev
