Writing an Alphanumeric Pager Server for Linux

The server is the workhorse of our operation. Servers process pager delivery requests (we'll call them jobs) and then deliver them via the IXO protocol over an available device.

Jobs consist of two very simple things: the profile to use and the message to send. How the server receives each job depends on how we want to structure it. I'll discuss two basic approaches here: TELNET-based and file-based servers. Each has advantages and disadvantages, and your choice of which to implement will depend largely on what sort of clients you want to support.

TELNET-based servers listen to a specific port on the host machine and use a simple protocol to send the profile and the message. A protocol such as:

profile

should suffice (provided, of course, that the strings identifying protocols don't contain newlines).

For security reasons, such servers should require some sort of authentication before accepting a job for delivery. The type of authentication we should use will depend strongly on our particular security needs, and is beyond the scope of this article.

A file-based server, on the other hand, watches a specific directory on the host machine (pausing for a brief length of time, then scanning its contents) and reads each new file, creates a job for it, then processes it; the file can be deleted when the server no longer needs it. The format of this file need be no different from the protocol of the TELNET-based server:

profile

As with TELNET-based servers, file-based servers need to consider security issues. The server would run as a specific group, and only programs which are part of that group may submit a job. When job files are created, they must be owned by the group and given group-writeable permissions (in a group-writeable directory), so that the server may delete files when it is done with them. An authentication scheme would also probably be useful here; at the very least, some simple encryption may well be in order.

Both TELNET- and file-based servers have their respective strengths. The most obvious for a TELNET-based server is it is quick and simple, and a client can be run on any machine that can be reached by the server using the telnet command. (Without adequate security considerations, this can also be a liability.)

The clients to file-based servers must run on the same machine (disregarding NFS-mounted directories for the sake of simplicity) and must be run by a user who is a member of the appropriate group. The most obvious advantage to a file-based server is that in the case of a server shutdown or a machine reboot, the pending jobs will still be waiting, whereas TELNET-based jobs must offload their pending jobs to disk (or to another server) if they are shut down.

Clients are the programs we use to send jobs to the server. At this point, writing the clients should be easy, since by choosing the type of server we are going to implement, we have implicitly chosen the type of client we must use to communicate with it.

Clients need to know how to contact the server, as well as verify that a profile is valid (the client should know when it has been asked to send a message to a nonexistent pager). To start with, we need a basic client, one we can run using the command line (or perhaps STDIN) to specify the profile and message and deliver a job—no frills, no fancy interfaces.

For file-based servers, this is a program (executable only by members of the appropriate group) which creates a job file in the appropriate directory with the appropriate permissions. With TELNET-based servers, the program can be run on any machine which has TELNET access to the machine on which the server runs and delivers the message via TELNET.

Once we have the basic client, we can move on to other types of clients. Here are two we might want to support:

In both cases, there are security issues to contend with. We certainly wouldn't want just anyone who has discovered the e-mail or web gateway to be able to send any page they wanted to anyone. The specifics regarding what sort of security precautions are advisable will depend strongly on the type of service we are running, so I will not go into detail about them here.