[Nut-upsdev] MGE NMC and NutShutdownModule (and other stuff)

[Marco Chiappero]

Arjen de Korte ha scritto:
> Citeren Marco Chiappero <marco at absence.it>:
>> 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