Asynchronous client communication

[aquette]

NUT clients currently have to poll upsd to get data.

To gain in SW power efficiency, we should implement asynchronous (event based) communication, from the drivers up to the client. This includes:

• [ ] Drivers: Support USB interrupt (need improvements?)
• [ ] Drivers: Support SNMP traps (#20)
• [ ] Drivers: Identify any other asynchronous HW protocols
• [ ] Drivers-Server: improve asynchronous use
• [ ] Client-Server: first implementation, only addressing ups.status (upsd - upsmon)
• [ ] Create a model of the current architecture
• [ ] Create a model and a specification of a new asynchronous architecture

Notes from clepple:

• http://tools.ietf.org/html/rfc2177 which includes an IMAP transcript with IDLE
• right now the clients have to poll the server the IDLE command could say "here is a list of variables to monitor; wake me when they change", and then the client goes into a longer sleep as part of select() for instance, upsmon doesn't care about line voltage but it does care about ups.status

[jimklimov]

A note for posterity: I was worried that this issue, as formulated, might concern itself with removal of polling in favor of messaging and/or pushing - this would be a step back in terms of reliability. And so I found there is nothing to worry about here ;)

Arnaud confirmed that indeed this feature is not planned as a replacement for polling, but rather as an addition: while the system is in non-critical states, async messaging (including broadcasts) and/or pushing would reduce the network loads and allow otherwise idling systems to stay throttled-down for longer stretches of time. Polling will be used, but with much lower frequency than is required today.

To quote: JIM>> ...As an example of polling as a good thing, I might remind of the upsmon behavior (IIRC) in case that an UPS is on-battery and suddenly there are no more replies to polls from a (remote) upsd: we assume that some networking gear’s source of power has already died due to the blackout, so the monitoring localhost should assume the worst and speedily shut down, even though the last known state was not low-battery. Abandoning polls completely would lose the ability to detect connection losses or driver problems (or new problems in new pieces of the complex stack, like the MQ service) - the clients would be fooled into thinking that nothing happens since they get no notifications.

AQU> For sure, it’s not a complete abandon: the dead-man sig (or heartbeat sig) is still part of the game, for the rationales you mentioned above. The base idea was that going through MQ allows both async (publish / subscribe) and sync (request / reply), and limit polling drastically, while not killing the system.