Writing an Alphanumeric Pager Server for Linux

For those thinking of setting up an alphanumeric paging service or gateway, this article explains the protocols and methods involved.

Alphanumeric pages—at least the type we
will consider here—are delivered via modem. To deliver a page, we
connect to our service provider, communicate with it through its
specified protocol, receive a confirmation that the page has been
delivered, then disconnect.

To send a message to someone, we need to know two things
about them: their pager service dial-up number and their PIN
(personal identification number). Alphanumeric pager owners should
be able to contact their pager service provider and get this
information with little trouble.

Protocol

Several protocols are used for delivering pages. The most
popular (and among the simplest) is IXO, named after the company
which invented it. It's also been called TAP (Telocator Alpha-entry
Protocol) and PET (Personal Entry Terminal); these names were
assigned to it by other companies over its history.

In this article, I will talk solely about the IXO protocol.
It is a bit involved so I won't go into great detail, but it is
relatively straightforward. In brief summary, here is a description
of the overall transaction between the remote dial-up site (us,
when delivering a page) and the pager service provider.

First, we establish a connection and get the service's
attention. After the service acknowledges our intent to transmit a
message, we declare our wish to enter automatic mode—this is the
simplest method through which to transmit a message, although in
rare cases we may want to use manual mode.

We wait for the service to acknowledge our request. When we
get the go-ahead signal to send the content of our message, we send
a series of fields. Usually we would send two fields, consisting of
the PIN of the pager to which we wish to send a message, and the
message. We follow the message with a checksum, so the provider can
verify (to some degree) that our message has been faithfully
received. Finally, once we receive an acknowledgement that our
message has been received, we politely request to be disconnected
and drop carrier.

The IXO protocol (see Resources) supports sending multiple
pages to the same service, but not necessarily the same pager,
during a single transaction. Thus, this method provides the
possibility for optimization in a large-scale service, if we find
many pages are being sent concurrently to people using the same
service, i.e., the same dial-up number.

Profiles and Devices

To start with, we'll need a mechanism for identifying each
pager to which we want to send messages; we'll call them
profiles. As mentioned earlier, there are two
things we need in order to be able to send messages to a particular
pager: the phone number of its pager service and the PIN of that
particular pager. These may be kept in configuration files, which
an administration program can edit and delete.

If we want to support multiple modems—that is, the ability
to deliver multiple pages simultaneously—we also need to know
about and keep track of the physical modems. We'll call them
devices. As with profiles, we'll keep a list
of the devices allocated to our server in a configuration
file.

Concurrent page delivery should take advantage of
multiprocessing; use fork to send
multiple pages simultaneously with different devices. This makes
things much simpler in terms of the overall flow control and
doesn't pose any significant problems, since we can simply check
the exit status (succeed or fail) of the subprocess through
waitpid and take action
accordingly.

We'll keep the list of devices handy, and when we are
delivering a page using one, flag it as busy. Unless we're going to
be running on a system where the modems are dedicated solely to our
server, we will almost certainly want to use standard lockfiles, in
addition to flagging the devices as used. (Even if the modems truly
are dedicated, it can't hurt to be extra careful.) This will
prevent other processes from interfering with our server while it
is actually in the process of delivering a page.

Filters

Alphanumeric pagers tend to be limited in terms of how many
characters a message can display; the typical maximum-length
support with the IXO protocol is 256 characters, including the PIN
expressed as a string, so in practice it's usually closer to
250.

People who get a lot of pages frequently run into this limit,
particularly when longer messages (such as e-mail or notes) are
being sent. A useful solution is to implement a
filter, which processes messages to be sent
and does simple searches and replaces in order to substitute
shorter equivalents for commonly appearing words and phrases. For
instance, the word “and” might be represented with an ampersand
(&), “talk to you later” might be abbreviated TTYL, and so
on.

Filters could also be used to provide a form of security
through obscurity. With most pagers, messages delivered over the
airwaves are not secure; anyone with the right equipment can
intercept them. This means, obviously, that the average person
would probably not want their name, address and other private
information being transmitted over the air. A simple choice of
filters could replace this sensitive information with abbreviations
recognizable to the party receiving the page, but meaningless to
anyone else.

It would also be straightforward to implement a filter based
on regular expressions, using the POSIX regex library. Since both
the simple and regular expression searches are relatively
straightforward, I will leave them as an exercise to the
reader.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.