Network UPS Tools User Manual

Network UPS Tools User Manual 82 / 84
J.4 Leaving 0.x territory
J.4.1 August 2002: first stable tree: NUT 1.0.0
After nearly 5 years of having a 0.x version number, 1.0.0 was released on August 19, 2002. This milestone meant that all of
the base features that you would expect to find were intact: good hardware support, a network server with security controls, and
system shutdowns that worked.
The design was showing signs of wear from the rapid expansion, but this was intentionally ignored for the moment. The focus
was on getting a good version out that would provide a reasonable base while the design issues could be addressed in the future,
and I’m confident that we succeeded.
J.4.2 November 2002: second stable tree: NUT 1.2.0
One day after the release of 1.0.0, 1.1.0 started the new development tree. During that development cycle, the CGI programs were
rewritten to use templates instead of hard-coded HTML, thus bringing back the flexibility of the original unreleased prototype
from 5 years before. multimon was removed from the tree, as the new upsstats could do both jobs by loading different templates.
A new client library called upsclient was created, and it replaced upsfetch. This new library only supported TCP connections,
and used an opaque context struct to keep state for each connection. As a result, client programs could now do things that used
multiple connections without any conflicts. This was done primarily to allow OpenSSL support, but there were other benefits
from the redesign.
upsd and the clients could now use OpenSSL for basic authentication and encryption, but this was not included by default. This
was provided as a bonus feature for those users who cared to read about it and enable the option, as the initial setup was complex.
After the 1.1 tree was frozen and deemed complete, it became the second stable tree with the release of 1.2.0 on November 5,
2002.
J.4.3
April 2003: new naming scheme, better driver glue, and an overhauled protocol
Following an extended period with no development tree, 1.3.0 got things moving again on April 13, 2003. The focus of this tree
was to rewrite the driver-server communication layer and replace the static naming scheme for variables and commands.
Up to this point, all variables had names like STATUS, UTILITY, and OUTVOLT. They had been created as drivers were added
to the tree, and there was little consistency. For example, it probably should have been INVOLT and OUTVOLT, but there was
no OUTVOLT originally, so UTILITY was all we had. This same pattern repeated with ACFREQ - is it incoming or outgoing?
- and many more.
To solve this problem, all variables and commands were renamed to a hierarchical scheme that had obvious grouping. STATUS
became ups.status. UTILITY turned into input.voltage, and OUTVOLT is output.voltage. ACFREQ is input.frequency, and the
new output.frequency is also now supported. Every other variable or command was renamed in this fashion.
These variables had been shared between the drivers and upsd as values. That is, for each name like STATUS, there was a #define
somewhere in the tree with an INFO_ prefix that gave it a number. INFO_STATUS was 0x0006, INFO_UTILITY was 0x0004,
and so on, with each name having a matching number. This number was stored in an int within a structure which was part of the
array that was either written to disk or shared memory.
That structure had several restrictions on expansion and was dropped as the data sharing method between the drivers and the
server. It was replaced by a new system of text-based messages over Unix domain sockets. Drivers now accepted a short list of
commands from upsd, and would push out updates asynchronously. upsd no longer had to poll the state files or shared memory.
It could just select all of the driver and client fds and act on events.
At the same time, the network protocol on port 3493 was overhauled to take advantage of the new naming scheme. The existing
"REQ STATUS@su700", "ANS STATUS@su700 OL" scheme was showing signs of age, and it really only supported the UPS
name (@su700) as an afterthought. The new protocol would now use commands like GET and LIST, leading to exchanges like
"GET VAR su700 ups.status" and "VAR su700 ups.status OL". The responses contain enough data to stand alone, so clients can
now handle them asynchronously.