Network Design

 

DATA TRANSFER


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.
 

CLIENT/SERVER COMMAND INTERFACE


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.
 

SERVER


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:
 

CLIENTS


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: