|
|
|
|
|
|
|
|
How one company has used Linux to provide transmission of live audio and video over the Internet.
by Gerald Crimp
Linux has garnered much attention in the mainstream press recently. Such publicity has been both a boon to Linux enthusiasts and advocates, and a source of curiosity to those who may just be learning of this marvelous operating system. I am very encouraged to see Linux growing in popularity. It's always pleasing, however, to see this popular media attention complemented by concrete examples of Linux in everyday use. As one of those fortunate individuals who gets paid for his passion, I would like to provide one such concrete example by sharing details of how we use Linux at Global Media Corporation.
Global Media Corporation (http://www.globalmedia.com/) is a publicly traded company that has built a private network for the transmission of live audio and video over the Internet. For Network Associates who want to stream their content and/or offer merchandise through electronic commerce, we provide a ready-made infrastructure based on Linux.
I work on the Network Engineering team (see Figure 1) where Linux is the heart and soul of what we do. Credit for this commitment to Linux goes to Marco Belmonte, our Technical Lead. When the Powers That Be were planning the whole project, Marco told them of Linux. He showed them how Linux would provide a reliable, scalable, flexible network and be cost-effective. We haven't looked back.
To broadcast over the Internet, we send a Linux box to the Network Associate. This is most often a radio station, but can be anyone with an audio source. The box is connected to our Network Operations Centre (NOC) and to an Internet access point over our private frame-relay lines. From the NOC, we can monitor, control, configure and update all the remote stations.
The boxes consist of Intel Celeron-400 chips on Abit socket 370 ZM6 motherboards with 64MB of RAM. The motherboards are equipped with Winbond monitors to ensure we can detect intrusion and track temperatures, voltages and fan speeds. This is important so that we can ward off problems that might cause the box to crash--no broadcaster likes dead air. The audio feed enters the box through a SoundBlaster 128 card. The encoded signal leaves the box through a Sangoma S508/FT1 WAN card. A 14.4 Hayes-compatible modem allows us to carry out emergency maintenance should something happen to the frame-relay connection.
This is a good moment to offer special recognition to Sangoma Technologies. As mentioned, Sangoma is the maker of the WAN cards (see Figure 2) we use to connect our boxes to the frame-relay network. Sangoma is also one of the few hardware manufacturers that has recognized and supported Linux from its earliest days. In the context of Global Media, this recognition is particularly appropriate, as they spent many hours adapting their software so we could configure their cards from a script rather than interactively.
Returning to our setup, the encoding boxes run a customized distribution of Linux. Since the machines would never have been used as workstations and only a few services were needed, the boxes were stripped down to core libraries and utilities. Added to this slimmed-down distribution were special configuration and monitoring scripts and the software for digitizing the audio signal.
To avoid the work of installing our distribution on every machine, the boxes are built from cloned disks. The cloning of disks and assembly of boxes is contracted out. The contractor ships a box to a new site after entering a unique identifier we specified. This identifier serves to configure the machine once it arrives at its destination.
Configuration is done over the wire by automated scripts. We chose this method for a number of reasons. First, as the boxes are shipped directly from the point of assembly, we have no opportunity to do the work ourselves. Second, security concerns dictated that we not provide elements of the configuration information to third parties. Next, we wanted the setup and operation of the box to be as simple as possible for our customer: they should only have to plug in the box and turn it on. Few clients, if any, would be comfortable running Linux commands on a text console. In addition, leaving this to the customer would increase the potential for typos and other related errors that would likely cost us many hours on the phone, trying to debug the problem. Finally, configuring machines by hand is drudgery best left to machines.
Automation ensures the boxes are configured and operational, both quickly and securely. Upon receipt of the box, the customer first attaches all the cables, then turns it on. From the boot scripts, a configuration client detects that the box has not yet been configured and contacts a configuration server in our NOC. Using the identifier sent by the remote box, the configuration server queries a PostgreSQL database to acquire all the appropriate information. Once the client has configured itself, it becomes part of our broadcast network. From that moment on, any audio coming into the box is available for listeners on the Net.
I mentioned we use private frame relay to pick up our audio signals. We could have simply used the Internet for this, but chose a private network in order to ensure the quality of the signal as far as possible along the path to the end listener. Using the Internet to gather our signals would have subjected us to congestion and competition for IP bandwidth. We would be forwarding to listeners an already degraded signal. We don't simply want to get listeners to their destination; we want to get them there in style.
RealNetworks--one of Global Media's partners--is our link to the Internet. RealNetworks relays our audio streams to their globally distributed network of servers. When a listener requests one of our URLs, RealNetworks determines the origin of the request and delivers the stream from the closest point. Thus, the portion of the total route that the requested stream has to travel over the Internet before reaching the user's player is reduced to a minimum. For the rest of the route, the stream travels over dedicated high-speed lines.
RealNetworks also provides us with the software that encodes the analog audio source (it runs on Linux) and the Global Media Player. RealPlayer and RealPlayer G2 can be used to listen to our streams, but the Global Media Player links the stream to the Network Associate's editorial content and storefront.
E-commerce is all about web servers and databases. In addition to providing the page that the end user sees, web servers coordinate taking orders, verify credit card information and order fulfillment. The databases contain all information concerning the available merchandise and the static and dynamic content populating the served web page.
During the early stages of Global Media's growth, a third party handled this part of the business. Now that Global has a complete technical team, its web serving has been moved in-house. The web development firm was using a combination of Cold Fusion, SQL Server and Internet Information Server on NT. We found the whole situation less than ideal; it was ridiculously resource-intensive and slow. Scalability was also a concern.
The immediate concern when transferring the system, however, was to keep it running. Now that things are reasonably stable, the task of migrating the works to Linux has begun. Moving the static content to Apache on Linux is the first phase. Next, portions of the database will be moved from the SQL Server to Texpress for Linux. The final phase will be the transfer of financial transactions.
Although Texpress is a commercial database, it is worthy of a quick comment. It uses an interesting algorithm for text searches, building bit-pattern indexes. Lightning-fast, it is worth a look on some rainy day.
Just as most of the broadcast network is located remotely--close to the audio sources--so most of the e-commerce network is far away, close to the big pipes. The Network Operations Centre is responsible for control and monitoring of all these remote machines.
For monitoring, we rely on SNMP (Simple network management protocal) and good old log files. We scan the logs in real time using the handy little utility swatch. When a message of interest is logged, swatch initiates the prescribed action. SNMP supplements and complements the log files by allowing an even finer-grained view of the inside of each box.
SNMP is the one place within the NOC where we were forced to find a solution outside of open source. On the broadcast network, the management end of the SNMP link uses HP OpenView on a Sun workstation. We did look at various Linux solutions for monitoring network and system information. Most of the functionality was available here and there, but not in a single tool, and it was not always stable. The state of the hardware in the audio-encoder boxes as well as the state of the encoding software and of the frame-relay link is fundamental to the success of our business. We needed something that could receive traps, discover network nodes, poll network nodes, and given the large number of nodes involved, graphically represent the whole. Commercial software seemed to be the only solution.
Nevertheless, the rest of the SNMP system runs on open systems. On the e-commerce side, where there are fewer nodes and polling is sufficient (i.e., no traps are used), NetSaint does the monitoring. Of course, the Linux boxes all use GNU SNMP agents. In fact, it is the open code that allows us to receive DMI (desktop managment interface) information from the audio boxes. The SNMP source code was modified so we could poll the encoder boxes for information concerning CPU temperatures, fan speeds and voltages.
Thanks to Linux, we did not need to make any expensive maintenance requests of vendors. Given these fine freely available tools, we can detect and fix trouble without the customer even knowing that anything was wrong.
One last Linux feature needs to be mentioned before closing. We shape the traffic on our pipe while the audio signal moves through our network toward the Internet. Sound quality depends on available bandwidth. One of the cornerstones of our business plan is high-quality sound; therefore, we have to protect the sound as far down the pipe as possible. The audio signal shares the pipe with monitoring and management traffic. Under normal circumstances, this should not present a problem. However, should a sudden surge in log activity occur or a new software package be sent back up the line, traffic shaping allows us to ensure it does not cut into the bandwidth required for our customer's broadcast.
Global Media Corporation produces the best audio signal possible for Internet listeners, while providing a cost-effective solution to broadcasters. Without Linux, we could not have achieved all we have as cheaply and effectively. Open source permits great independence. If the system had been built using a commercial operating system, we would have been subject to the cost and delay of vendor customizations, that is, if the vendor was even willing to consider making any modifications.
Many businesses still regard Linux and other open-source software with suspicion. It is still often perceived as a hacker toy unsuitable for real work. We hope our experience will help dispel such myths and encourage others to consider Linux as a viable work tool.
Gerald Crimp (gcrimp@globalmedia.com) is a software engineer at Global Media Corporation in Vancouver, BC, Canada. Debian is his distribution of choice. He looks forward to the day when Linux takes over the desktop.