Figure 1. VT-100 terminals used to be connected to mainframes using RS-232 connections. In the ’80s, the IBM PC and Apple IIe combined the computer, display drivers and keyboard I/O into one box. Now, PCs and Macs use telnet and SSH over the Internet to create a virtual terminal session. Click here to see an enlarged diagram.
Remote monitoring and control of broadcast facilities is nothing new. Does anyone remember transmitter remote control systems based on telephone stepper relays? As the years have passed, remote monitoring capabilities have increased, driven by the consolidation of facilities, economies of scale and perhaps the engineer's natural propensity to do cool things with equipment that is far away.
Remote commandline access
Traditionally, broadcasters have focused on remote monitoring and control of transmitters. But now it is possible to remotely monitor and control all sorts of equipment.
As broadcasters have deployed more computer infrastructure in remote facilities, the need for monitoring and control of this infrastructure has grown. Let's take a look at the options available.
All computer access was remote at one point. The mainframe sat in a computer room, and terminals were located somewhere else. The terminals were usually Digital Equipment model VT-100s, and they were connected to the mainframe by RS-232. (See Figure 1.) It wasn't until the early '80s that Apple, Tandy, IBM and others introduced consumers to small systems with the terminal and computer all in one box. This all-in-one construction eliminated the need for a separate terminal.
Fast-forward about 10 years, and ironically, the need for remote terminals to be connected to central servers reappears. Internet servers are typically located where they can have access to high-speed network connections, but people who maintain these servers could be anywhere.
What people needed was an application that could be run on their local computer that would turn it into a remote terminal on their Internet server. This is exactly what telnet does. Telnet is an application that emulates a computer terminal (usually a VT-100).
To connect to a remote computer, you type “telnet hostname [port]” at a command line. From that point on, your computer acts as if it is a terminal connected by a serial cable to a mainframe. The port command is optional and defaults to port 22 for telnet. Many administrators disable telnet on computers that have Internet connections because of security concerns; telnet sends everything you type (including user names and passwords) in the clear.
Remote GUI access
Many, if not all, UNIX system administrators still use telnet-type connections because they prefer to work with command line utilities. They find that with experience, they can do many jobs more quickly from the command line than they can when using a graphical user interface (GUI). Telnet would be the perfect tool to use in this case because it provides remote command line access to a server. However, system administration commandfrequently contain information that administrators would prefer to keep secret — for example, the root password for the server. A more secure version of telnet was required.
Secure shell (SSH) was developed to provide remote, secure terminal access to computer systems. Functionally, SSH is almost identical to telnet, with the notable exception that all communication across an SSH connection is encrypted. It provides an authentication layer with advanced capabilities. To learn more about SSH and authentication, visit www.openssh.org.
While command-line access addresses the needs of many server administrators, there are other times when administrators and users need access to a GUI.
GUI-based remote control applications have existed for many years. LapLink was developed in the mid-'80s to provide command-line remote access to PCs. Timbuktu provided similar functionality for Apple machines. By connecting a modem to your computer at work and then calling that modem from home, these applications allowed you to work with files and print, as well as perform other common chores. from a remote location.
The performance of these applications over a telephone line was slow but acceptable. When Apple developed the Mac, and Microsoft developed Windows, this created a problem for users who required remote access. The GUIs required that much more information be transmitted across the telephone line. While it was possible to operate a GUI system remotely, performance was a problem, and interactivity was difficult.
Fast-forward to today, and several things have changed. First, most installations are now interconnected with modems that run at much higher speeds (56Kb/s compared with 1200 baud in the mid-'80s).
Remote control and monitoring
Second, most critical facilities and a majority of homes are served by Internet connectivity that operates at 512Kb/s or higher.
Third, computer engineers have figured out how to dramatically reduce the amount of bandwidth needed for remote control of a GUI system. Now, instead of sending the entire screen, the data on the link represents only what has changed in the image. Not only does this cut the bandwidth required, but also it reduces the processing time required in the server and client so that delay is minimized. If you run a firewall, you will probably have to change its configuration for these remote control applications to work properly.
While telnet, SSH and various GUI remote applications take care of one area of interest for broadcasters, they omit another. Namely, they do not provide a view of what is happening on the network. An SSH session might tell you that your server is experiencing an unusual load, but it would not tell you where the traffic is originating on your network. Computer network engineers have used the Simple Network Monitoring Protocol (SNMP) for years to provide them with a view of what is happening on their network. SNMP provides an easy way for network devices (agents) to report various parameters back to a central monitoring system (manager).
SNMP-enabled systems may provide information on port traffic, power supply voltages, fan speeds and so on. In addition, SNMP supports commands and traps. Commands allow a remote user to change the configuration of a device. Traps provide a way to remotely monitor a system and to be notified when some parameter goes out of tolerance.
One of the great benefits of SNMP is that it provides a standardized way to monitor computer networks. In many cases, you can use SNMP agents from various manufacturers with a single SNMP manager. This allows you to mix equipment from different manufacturers in your network and still manage it from a central location.
Advanced system monitoring
One of the good things about SNMP is that the core can be expanded to support functionality that was not originally- anticipated. SNMP is beginning to be accepted within the broadcast community, and some standardized SNMP extensions are being incorporated into shipping equipment. As computer-based broadcast facilities become more common, it will become more common to find SNMP agents in broadcast equipment.
A word of warning about SNMP control: SNMP control was never intended for real-time control of broadcast equipment. It was to be used to do things such as change the configuration of a particular port on an Ethernet router. SNMP control is completely non-deterministic, meaning that, within reason, there is no way to know when the command will be executed. In some broadcast applications, this type of control works well. Turning on studio lighting is an application where it does not really matter if the command is executed in 200ms or 2s. But this sort of variability would be completely unacceptable in most broadcast applications.
You may have heard about computer systems that have the capability to call your pager or send an e-mail when something goes wrong. Let's look at one implementation to see how these systems work.
I have two IBM 330 e-Series single rack unit servers. I monitor the health of both of these servers using IBM Director, a software package written expressly for this purpose.
Figure 2. IBM 330 servers contain an advanced system management (ASM) processor, in addition to the main CPU. The independent ASM processor can communicate with Director software. Director is responsible for monitoring the output of the ASM and notifying a system administrator via pager or e-mail message if server parameters are out of limits. Click here to see an enlarged diagram.
The e-Series servers are a little unusual in that they have a completely separate processor (called the advanced system management, or ASM processor) dedicated to monitoring and reporting on the server itself. (See Figure 2.) The ASM runs whether the computer is turned on or not, allowing you to send commands to start, stop, reboot and perform other system maintenance commands, even if the main processor is locked up.
The ASM processors communicate with the Director. As administrator, I can configure IBM Director to monitor numerous parameters on multiple servers and send me notification when these parameters fall out of preset limits. I can connect to the ASM over the Internet (through a VPN for security purposes) to send control commands to the servers as required.
I have found remote reporting and management capability invaluable. If you have never worked with hardware and software that has this capability, I suggest you give it a try.
A long time ago, sharp broadcast engineers developed various remote control technologies so that they could do their jobs quickly and more efficiently. That trend continues today as broadcasters move to computer-based technologies. Fortunately, telnet, SSH, remote GUIs, SNMP and advanced management tools are available to the broadcast computer engineer.
Brad Gilmer is president of Gilmer & Associates, executive director of the AAF Association and executive director of the Video Services Forum.
Send questions and comments to:brad_gilmer@primediabusiness.com
