Arjen de Korte ha scritto:
Citeren Marco Chiappero <[email protected]>:
Yes, if we do care about detailed info. The summary page can be enough
for that, but at this point we should introduce changes in the
netxml-driver and a new configuration key (such as "extended = true")
which is not good.
The summary page can be also quite large (depending on the model you
have) so this doesn't really help to reduce the load on the NMC. Since
the way we get information from the NMC is quite different between the
polling mode that is used by the netxml-ups driver and the subscribed
mode for NSM clients, I really don't want to combine these in one driver.
Well, from the practical point of view they are indeed very similar:
when the driver is required to provide updated data through the
upsdrv_updateinfo call, it just reads XML data from both the http and
nsm tcp sockets (more or less directly - I used libneon for both), if
data are available. But this is true for the NSM tcp protocol, where,
apart from the initial key, the client it is not supposed to interact
with the NMC, as far as I've seen. While, if I remember correctly, with
the udp protocol, the client is required to reply, for example when
scanning for managed/subscribed clients. This can be a complication and
it is another reason why I preferred to implement the tcp protocol at
the moment.
This is what I have seen sniffing the network traffic, and I'm not
totally totally sure it works always like I said.
Nonetheless there's no way out if we want many variables, we have to
read a "lot" of data from every single UPS involved and stress the
NMC, even though UDP can help.
For various reasons, using UDP for collecting data from the UPS is not a
good idea.
Ok, so let's discard the NSM protocol through udp... but at this point
the subdriver approach can be interesting.
BTW, why not a good idea?
Maybe we can use the summary page, by default, when the management is
enabled, or use different poll intervals for management and data...
Newer versions of the netxml-ups driver already do so by default.
?
I'm talking about reading the get_object.xml data less often than the
data sent by the management communication.
Later you replied:
" This might be an option, but for logging purposes a full poll every 60
seconds is probably not nearly enough."
Maybe a little misunderstanding...
Yet,
this still doesn't fully solve the problem and you really should not run
more than one netxml-ups driver on any single NMC (regardless of which
version you have).
Sorry, I don't understand what you mean, please explain a little bit.
Please do follow up on the NSM driver, but make this a separate one (so
don't include it in the netxml-ups driver). This not only reduces the
load on the NMC, but it will also make the code much cleaner, since you
don't have to deal with the differences between connected and
non-connected mode (it would always use connected mode). The mapping
between variables for values read from the UPS to NUT variables would
also be reduced significantly and basically you'd only have to parse the
ones from the ALARM messages.
Correct. But what about redundant configurations? Have to be managed
here? And lastly, I'm not that sure, but if some replies are needed from
the client I'm afraid that we are unable to reply due to the relatively
high poll interval (a blocking read should be used instead, and we can't
without creating a new process). I've never thought about that before...
I have to study the udp protocol a little bit.
Regards,
Marco
_______________________________________________
Nut-upsdev mailing list
[email protected]
http://lists.alioth.debian.org/mailman/listinfo/nut-upsdev
