Writing an Alphanumeric Pager Server for Linux
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.
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.
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.
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.
|Using Salt Stack and Vagrant for Drupal Development||May 20, 2013|
|Making Linux and Android Get Along (It's Not as Hard as It Sounds)||May 16, 2013|
|Drupal Is a Framework: Why Everyone Needs to Understand This||May 15, 2013|
|Home, My Backup Data Center||May 13, 2013|
|Non-Linux FOSS: Seashore||May 10, 2013|
|Trying to Tame the Tablet||May 08, 2013|
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- Validate an E-Mail Address with PHP, the Right Way
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Download the Free Red Hat White Paper "Using an Open Source Framework to Catch the Bad Guy"
- Tech Tip: Really Simple HTTP Server with Python
- Home, My Backup Data Center
- Android is Linux -- why no better inter-operation
57 min 21 sec ago
- Connecting Android device to desktop Linux via USB
1 hour 25 min ago
- Find new cell phone and tablet pc
2 hours 23 min ago
3 hours 52 min ago
- Automatically updating Guest Additions
5 hours 1 min ago
- I like your topic on android
5 hours 47 min ago
- Reply to comment | Linux Journal
6 hours 9 min ago
- This is the easiest tutorial
12 hours 23 min ago
- Ahh, the Koolaid.
18 hours 2 min ago
- git-annex assistant
1 day 1 min ago
Enter to Win an Adafruit Pi Cobbler Breakout Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Pi Cobbler Breakout Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- 5-21-13, Prototyping Pi Plate Kit: Philip Kirby
- Next winner announced on 5-27-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.