2011/6/29 Arjen de Korte nut+de...@de-korte.org
Citeren Arnaud Quette aquette@gmail.com:
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
2011/6/30 Charles Lepple clep...@gmail.com
On Wed, Jun 29, 2011 at 3:56 PM, Arnaud Quette aquette@gmail.com
wrote:
2011/6/29 Charles Lepple clep...@gmail.com
To be honest, I'm not terribly excited about the notion of a NUT scanner
just to disambiguate your words for Fred and
Citeren Stuart D Gathman stu...@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
Citeren Charles Lepple clep...@gmail.com:
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
On Wed, 2011-06-29 at 07:13 -0400, Charles Lepple wrote:
On Jun 29, 2011, at 3:29 AM, Arjen de Korte wrote:
Citeren Stuart D Gathman stu...@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
Citeren Charles Lepple clep...@gmail.com:
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
2011/6/29 Charles Lepple clep...@gmail.com
On Jun 29, 2011, at 3:29 AM, Arjen de Korte wrote:
Citeren Stuart D Gathman stu...@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
Citeren Arnaud Quette aquette@gmail.com:
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
On Wed, Jun 29, 2011 at 3:56 PM, Arnaud Quette aquette@gmail.com wrote:
2011/6/29 Charles Lepple clep...@gmail.com
To be honest, I'm not terribly excited about the notion of a NUT scanner
just to disambiguate your words for Fred and others: you were probably
referring to nut-scanner
On Wed, Jun 29, 2011 at 4:13 PM, Arjen de Korte nut+de...@de-korte.org wrote:
as for the compat, IIRC Fred proposed a a new _tryconnect() method, upon
which the standard _connect() would be mapped, with no behavior change.
It is still unclear to me what we're trying to accomplish here, since
Hello,
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. So the nut-scanner is
blocked while waiting for the TCP timeout when trying to connect to an
IP
On Jun 28, 2011, at 4:51 AM, Frédéric Bohé wrote:
I propose to add a upscli_tryconnect function accepting a timeout
parameter, which will be the copy of the current upscli_connect + the
management of the timeout. The upscli_connect will be only a wrapper
on
top of upscli_tryconnect, calling
Citeren Frédéric Bohé fredericb...@eaton.com:
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.
This is a serious problem, not only for the nut-scanner
On 06/28/2011 02:29 PM, Arjen de Korte wrote:
Citeren Frédéric Bohé fredericb...@eaton.com:
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
14 matches
Mail list logo
