First issue is which kind of data transfer use to solve the endianess
problems and size of basic data types. Since the beginning I wanted to
implement the data transfer in ascii form that allow us to forget about
endianess and size of types. Transferring in ascii gives us these benefits:
As discussed with Kern, ASCII data transfer does not alone solve
every problem. In 32/64 bits architectures the use of sscanf may force
us to pick correctly the format strings. I think we can deal with this
on a per-architecture basis as this is the only customization needed for
the data transfer to work correctly.
Another thing discussed with Kern is transmission format. The initial
design is totally ASCII for ease of debugging. In the future, if we will
need, we can switch to semi-binary interface where we announce the number
of transmitted lines before starting a transmission.
As for data transfers, the client/server command interface is in
ascii form. This design allowed to reuse the same interface for commands,
answers and UPS data transfers. This command interface is a set of commands
that the client can give to the server to ask for data. This command set
is easily expandable and even if expanded, will mantain total backward
compatibility with the initial implementation. In the future we will add
for example front panel led test command but this will be totally transparent
and clients of previous 4.x versions will be always able to talk with the
new daemon as the older commands will not be touched. The command interface
have commands for:
The command set as defined is not definitive. Don't forget that
we are still in alpha devel so I'm ready to change/add commands. To obtain
a full list of the server command set, please look into daemon/apcnetcmd.c.
The server is an apcupsd child that will serve (based on config
file directives) the UPSes info over the network. The daemon do not fork
but instead uses select() on multiple file descriptors. To handle slow
clients it reads data in O_NDELAY so that a slow client will not block
other, faster, clients. With this architecture I'm sure the apcupsd is
able to handle thousand of clients regardless of the speed of their connection
with only very limited delay (read the already available data and process
them). Security checks include:
The advantages of this design include:
We can have different kinds of clients, but they will all share
the same communication layer. The network layer of apcupsd is built to
deliver all the information known to the server and not only a subset,
like the current 3.x implementation. The advantages of this are: