A Perl script implements a singing, musical Internet
Catchy Logs
Instead of just monitoring incoming requests in your web server's logfile, a sound server makes them audible and lets you listen to the tune of users surfing the site.
Whenever I upload a new version of our blog-like newsletter [1], send an email announcement, or update the RSS feed, I tend to check the web server access log to watch the first information-hungry visitors read the latest news and click on the high-res images.
Of course, deciphering the server log entries scrolling by is fairly tedious. It would be much better to monitor the requests in the background and start working on something else in the meantime. One way to do this would be to transform web hits into sound. Many moons ago, I read in Netscape Time, by Jim Clark, that the early Netscapers used to output incoming hits via PC speaker after creating a new release [2]. A Netscape browser download for Windows croaked like a frog, the sound of breaking glass played for Macs, and Unix downloads were announced with a cannon shot. This meant that the Internet pioneers could share the sound of success in their cubicles after the long coding stretch that preceded the launch.
Implementing something like this in Perl is fairly easy. In my case, however, things are not quite as simple because the web server is somewhere in a hosting provider's server farm. Although the hoster allows ssh-based shell access, it can't transmit sound.
Firewall Tunnel
The boom-sender script on the hosting provider's shared server monitors the web server's access.log file and sends messages for specific URLs through an SSH tunnel to the boom-receiver sound server script running on my home PC.
Figure 1 shows the setup: The sound server is a script implemented by the CPAN POE module that listens for sound commands on port 8080 of the local machine. Another POE script runs provider-side, reacting to changes in the access log and sending messages home as a TCP client. Because my home machine resides behind a firewall, the boom-sender log checker can't talk to it directly. Instead, a tunnel setup that uses the command
home$ ssh -R 8080:localhost:8080 host.xyz-hosting.com
on my home PC connects the two dialog partners. The log script on the hosted server just has to send its messages to its local port 8080, and – hey presto – they are whisked away through the tunnel to port 8080 on the home PC as if the firewall never existed.
Sound on Demand
The local sound machine receives names of sound files in this way and proceeds to play them on Linux with the play utility from the Sox package treasure trove.
By default, the Play program is included with Ubuntu and can handle both WAV files and MP3s, assuming you configure Ubuntu to support this.
Figure 2 shows the interaction of a test client with the sound server running. The telnet command is launched to connect to localhost's port 8080 and receives a greeting from the server and a list of the sound files it has. When the client sends the name of one of these WAV files to the server, the server plays the file. For security reasons, only file names are allowed, rather than paths.
The default location in which boom-receiver looks for these sound files is the current working directory (.), specified as $SOUND_DIR in line 9 of Listing 1.
Because it offers a plethora of server and client components that just need to be put together in creative ways, POE is a good choice of server and client technology. The poe.perl.org website and the POE chapter in Advanced Perl Programming [3] both offer useful introductions to POE, which requires a non-traditional, event-based programming model that takes some time getting used to. The server in Listing 1 defines callbacks for the states ClientConnected (client has opened a connection), ClientInput (client has sent a line of text), and sound_ended, the state that handles the clean up work (described below) after playing a sound.
The sound server handles multiple client connections quasi-simultaneously. The POE component logic takes care of the low-level implementation details and ensures smooth request and error handling behind the scenes. Just like any other POE script, the program code first defines the behavior for any possible events and then calls POE::Kernel->run() to launch the POE kernel. The kernel runs until the program ends, until a fatal error occurs, or until the user terminates the script.
Listing 1
boom-receiver
Don't Dawdle
The sound_play() function in line 60 of Listing 1 plays a sound file passed to it by name. It creates POE::Wheel, a cogwheel in the POE system's works that allows the POE kernel to talk to the world outside.
To allow the system to process multiple tasks quasi-simultaneously, Perl code in POE should only run uninterrupted as long as it proceeds at full speed. Any interactions with files, sockets, or other processes obviously cause delays because disk or network access is far slower than processing CPU instructions or accessing RAM, and it would be extremely inefficient to let the CPU sit idle while waiting for these tasks to complete. Instead, they are handed off to wheels, which accomplish them one slice at a time and report results back asynchronously to the POE kernel.
Applying the play command to start a new Unix process, passing a short sound file to it, and waiting for it to play takes more than a second. If the script was blocked for this time, it would delay the client response and not be available for new requests.
Instead, a wheel is spun off with the process task, the callback returns immediately, and the POE kernel reassumes control, leaving everything else to run in the background.
The wheel – POE::Wheel::Run – expects as parameters an external program to launch, its arguments, and a StderrEvent callback, triggered if the process writes anything to its STDERR channel. Of course, this is not relevant for the Play program, which does not normally output error messages and simply terminates after playing a sound file. Boom-receiver simply defines a non-existing state for this event, which POE later ignores.
When the wheel notices that the play process has terminated, it triggers CloseEvent in line 75, assigned to a subroutine in line 48. Then it removes the remaining reference to the wheel from the system, which unleashes the POE kernel's garbage collector to clean up its remains.
Ideally, the wheel would just launch a process such as xmms, which would run permanently, and then occasionally pass sound files to it. However, the POE component for this on CPAN is badly out of date and won't compile with the current version of XMMS. Pity!
Buy this article as PDF
(incl. VAT)
Buy Linux Magazine
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters
Support Our Work
Linux Magazine content is made possible with support from readers like you. Please consider contributing when you’ve found an article to be beneficial.
News
-
OSJH and LPI Release 2024 Open Source Pros Job Survey Results
See what open source professionals look for in a new role.
-
Proton 9.0-1 Released to Improve Gaming with Steam
The latest release of Proton 9 adds several improvements and fixes an issue that has been problematic for Linux users.
-
So Long Neofetch and Thanks for the Info
Today is a day that every Linux user who enjoys bragging about their system(s) will mourn, as Neofetch has come to an end.
-
Ubuntu 24.04 Comes with a “Flaw"
If you're thinking you might want to upgrade from your current Ubuntu release to the latest, there's something you might want to consider before doing so.
-
Canonical Releases Ubuntu 24.04
After a brief pause because of the XZ vulnerability, Ubuntu 24.04 is now available for install.
-
Linux Servers Targeted by Akira Ransomware
A group of bad actors who have already extorted $42 million have their sights set on the Linux platform.
-
TUXEDO Computers Unveils Linux Laptop Featuring AMD Ryzen CPU
This latest release is the first laptop to include the new CPU from Ryzen and Linux preinstalled.
-
XZ Gets the All-Clear
The back door xz vulnerability has been officially reverted for Fedora 40 and versions 38 and 39 were never affected.
-
Canonical Collaborates with Qualcomm on New Venture
This new joint effort is geared toward bringing Ubuntu and Ubuntu Core to Qualcomm-powered devices.
-
Kodi 21.0 Open-Source Entertainment Hub Released
After a year of development, the award-winning Kodi cross-platform, media center software is now available with many new additions and improvements.