735 lines
38 KiB
Markdown
735 lines
38 KiB
Markdown
---
|
|
created_at: '2015-09-08T21:02:55.000Z'
|
|
title: 'Peep, the Network Auralizer: Monitoring Your Network with Sound (2000)'
|
|
url: https://www.usenix.org/legacy/publications/library/proceedings/lisa2000/full_papers/gilfix/gilfix_html/index.html?_
|
|
author: panic
|
|
points: 44
|
|
story_text: ''
|
|
comment_text:
|
|
num_comments: 10
|
|
story_id:
|
|
story_title:
|
|
story_url:
|
|
parent_id:
|
|
created_at_i: 1441746175
|
|
_tags:
|
|
- story
|
|
- author_panic
|
|
- story_10188193
|
|
objectID: '10188193'
|
|
year: 2000
|
|
|
|
---
|
|
[](http://www.usenix.org)
|
|
|
|
# Peep (The Network Auralizer): Monitoring Your Network With Sound
|
|
|
|
*Michael Gilfix & Prof. Alva Couch* - Tufts University
|
|
|
|
# Abstract
|
|
|
|
Activities in complex networks are often both too important to ignore
|
|
and too tedious to watch. We created a network monitoring system, Peep,
|
|
that replaces visual monitoring with a sonic \`ecology' of natural
|
|
sounds, where each kind of sound represents a specific kind of network
|
|
event. This system combines network state information from multiple data
|
|
sources, by mixing audio signals into a single audio stream in real
|
|
time. Using Peep, one can easily detect common network problems such as
|
|
high load, excessive traffic, and email spam, by comparing sounds being
|
|
played with those of a normally functioning network. This allows the
|
|
system administrator to concentrate on more important things while
|
|
monitoring the network via peripheral hearing.
|
|
|
|
This work was supported in part by a USENIX student software project
|
|
grant.
|
|
|
|
# Introduction
|
|
|
|
Are your systems and network functioning correctly? Can you be sure at
|
|
this moment? Every administrator has some need to be able to answer
|
|
these or similar questions on an ongoing basis.
|
|
|
|
Current approaches to live monitoring of network behavior (such as
|
|
Swatch \[10\], mon \[4\], and their many relatives) can send email or
|
|
page responsible people when things seem to go wrong. These tools are
|
|
both visual and intrusive; operators must either be interrupted by
|
|
alerts or periodically suspend other work to check on network status.
|
|
Furthermore, these approaches are highly *problem-centered* and provide
|
|
mainly *negative reinforcement*; the monitor notifies an operator only
|
|
when problems occur. It does not, as a rule, regularly inform one when
|
|
things are going well.
|
|
|
|
We created a tool Peep that represents the operational state of a system
|
|
or network with a *sonic environment*. The flavor, texture, and
|
|
frequency of sounds played are used to represent both proper and
|
|
improper network performances, while the \`feel' of the sounds provides
|
|
the listener with an approximation of network state. This environment
|
|
plays in the background while the operator continues other tasks.
|
|
Without looking anywhere and without interrupting other pressing
|
|
activities, the operator can hear *peripherally* whether action is
|
|
required.
|
|
|
|
# Auralization
|
|
|
|
The idea of auralizing network behavior by playing network sounds is not
|
|
new. Joan Francioni and Mark Brown \[3, 5\] represented parallel
|
|
computer performance using a synthesizer driven by a MIDI interface. The
|
|
strength of this approach, however, was also its main limitation. For
|
|
music to remain pleasant, one must limit one's representations to a
|
|
limited number of relatively pleasing harmonic combinations. This
|
|
greatly limits what one can represent with this technique. *Earcons*
|
|
\[2\] are the sonic equivalent of icons; sounds that are naturally
|
|
associated with particular events. For example, most people associate a
|
|
car horn with impatience or alert and a doorbell with someone entering a
|
|
house.
|
|
|
|
Both of these approaches define the meanings of specific sounds or
|
|
particular combinations in isolation. Combining sounds is difficult
|
|
unless they are consonant either musically or environmentally, that is,
|
|
that the sounds naturally occur together and \`sound right' in
|
|
combination. Natural sounds have an advantage over music; they sound
|
|
normal and pleasing in almost any combination similar to that of nature.
|
|
For example, birds and frogs in wetlands can sing with virtually no
|
|
coordination, and the result is still pleasing.
|
|
|
|
# The Psychology of Audio Notification
|
|
|
|
What makes Peep possible is that events in networks have easily
|
|
recognized natural sound counterparts. Moreover, numerous natural sounds
|
|
can be played in combination while the result stays pleasing to the ear.
|
|
If each sound represents some part of network function, and all are
|
|
played together, the result is a *sonic ecology* in which the current
|
|
state of the network can be determined moment by moment.
|
|
|
|
Peep exploits human instinct: our ability to notice a deviation from the
|
|
norm with little effort, to determine what sounds right, and to discern
|
|
singular important sounds from a collection of many sounds. We do these
|
|
tasks with little or no conscious effort. Since computer interfaces
|
|
mainly require the visual senses (and some motor skills), the audio
|
|
senses are left available to perform this unconscious processing.
|
|
|
|
Furthermore, Peep takes advantage of our ability to do abstract
|
|
processing. Instead of attempting the difficult and sensitive problem of
|
|
determining when a network crisis has occurred or is about to occur,
|
|
Peep provides contextual, continuous sound information and leaves
|
|
interpretation to the listener. Decisions are based not only on the
|
|
quantitative measure of things, but the relative amount and absence of
|
|
things. A musician friend has often expressed to me his philosophy:
|
|
\`\`Anybody can play drums, but the great drummer concentrates as much
|
|
on the feel of the notes as on the space, or absence of sound, between
|
|
them.'' Similarly, information that is lacking from Peep's sound
|
|
ambiance is just as important as the amount of information conferred and
|
|
the relative magnitude is left to the judgement of the listener.
|
|
|
|
# Representational Techniques
|
|
|
|
Sound representation in Peep is divided into three basic categories:
|
|
*Events* in networks are things that occur once, naturally represented
|
|
by a single peep or chirp. Network *states* represent ongoing events by
|
|
changing the type, volume, or stereo position of an ongoing background
|
|
sound while *heartbeats* represent the existence or frequency of
|
|
occurrence of an ongoing network state by playing a sound at varying
|
|
intervals, such as by changing the frequency of cricket chirps.
|
|
|
|
Peep represents discrete events by playing a single natural sound every
|
|
time the event occurs, such as a bird chirp or a woodpecker's peck. The
|
|
sounds we chose are short and staccato in nature and easily
|
|
distinguishable by the listener. Additionally, we noted that certain
|
|
events tend to occur together and found it convenient to assign them
|
|
complementary sounds. While monitoring incoming and outgoing email on
|
|
our network, we noticed that the two events were often grouped together,
|
|
since both types of email were usually transferred in a single session
|
|
between mail servers. To better represent this coupling between incoming
|
|
and outgoing email events and make the representation sound more
|
|
natural, we used the sounds of two conversing birds. Thus, a flood of
|
|
incoming and outgoing email sounds like a sequence of call and response,
|
|
making the sound \`imagery' both more faithful to our network's
|
|
behavior, as well as more pleasing to the ear.
|
|
|
|
State sounds correspond to measurements or weights describing the
|
|
magnitude of something, such as the load average or the number of users
|
|
on a given machine. Unlike events, which are only played when Peep is
|
|
notified of them, Peep plays state information constantly and need only
|
|
be signaled when state sounds should change. Peep represents a state
|
|
with a continuous stream of background sounds, like a waterfall or wind.
|
|
Each state is internally identified as a single number measurement,
|
|
scaled to vary from extremely quiet to loud and obnoxious. Background
|
|
sounds should be soothing while the network is functioning normally.
|
|
However, when the administrator is annoyed, he will know that action is
|
|
required.
|
|
|
|
Heartbeats are sounds that occur at constant intervals, analogous to
|
|
crickets chirping at night. A common folk tale is that one can tell the
|
|
temperature from the frequency of cricket chirps; likewise we can
|
|
represent network load as a similar function. Intermittent chirps might
|
|
mean low load, while a chorus might mean high load. Heartbeats can also
|
|
report results of an intermittent check (or ping) to see if a given
|
|
machine, device, or server is functioning properly.
|
|
|
|
Humans are very apt at recognizing when continual background sounds
|
|
change, making problem detection swift and simple. If your email server
|
|
dies, chances are that you will not receive any email warning of the
|
|
problem. But the crickets will have stopped chirping. The heartbeats
|
|
provide an effective method for monitoring the functionality of your
|
|
network and being alerted of a problem when all else fails, through the
|
|
absence of sound. Likewise, the administrator need not fear about
|
|
monitoring his Peep server; if it dies, he will be immersed in sudden
|
|
silence\!
|
|
|
|
Sound representation depends very much on personal taste. Peep aims to
|
|
provide users with a choice of themes such as *wetlands* (the current
|
|
theme available) or *jungle*. Within a theme, sounds are classified
|
|
according to the network events they most appropriately express.
|
|
Although the two chorusing birds were used to represent incoming and
|
|
outgoing mail in the previous example, the two bird sounds could have
|
|
been used for any type of coupled event behavior. These classifications
|
|
help the user make decisions on what sounds to use from his collection
|
|
of favorites.
|
|
|
|
We also recognize that distinguishing sounds can be difficult if, for
|
|
example, several similar bird sounds are used in a single theme. As the
|
|
theme repository provided with Peep expands, we hope it will address a
|
|
wide range of network situations and personal tastes.
|
|
|
|
# Scalability and Flexibility
|
|
|
|
The Peep architecture was designed to be versatile and scalable. The
|
|
architecture is based upon a producer/consumer relationship between
|
|
distributed monitoring processes that watch the network and servers that
|
|
actually play sounds. Producers alert consumers to events and state
|
|
changes via short UDP messages, as shown in Figure 1.
|
|
|
|
This architecture allows the receipt of status reports from any number
|
|
of devices or nodes. Producers (the monitors in Figure 1) monitor
|
|
network behavior and report events and states while consumers take their
|
|
input from the producers and play the appropriate sounds. Producers can
|
|
be pointed at several sound generators simultaneously, e.g., a lab full
|
|
of Linux workstations, for a truly immersive experience\!
|
|
|
|
|
|
**Figure 1**: The Peep architecture.
|
|
|
|
|
|
Producers are executed as daemons on machines with access to information
|
|
sources. This eliminates the need to send copious amounts of sensitive
|
|
log or machine information across the network to a centralized
|
|
monitoring server. The packets sent to the consumer contain only sound
|
|
representation information and would be of little use to a snooper
|
|
without access to the Peep configuration file.
|
|
|
|
The Peep system was designed to take advantage of existing system
|
|
administration tools. Server and client configuration information is
|
|
stored in the same configuration file. This allows centralized control
|
|
of Peep via simple file distribution via NFS or other widely accepted
|
|
mechanisms such as CFEngine \[6, 7, 8\] and rdist \[9\].
|
|
|
|
Clients provided with the Peep distribution are \`lightweight' Perl
|
|
scripts. Each client functions strictly within one problem domain: it
|
|
addresses its original intended purpose and no more. This keeps client
|
|
code simple, easy to debug, and easy to customize.
|
|
|
|
We also wanted clients to run in the background and utilize as little
|
|
resources as possible. Our log probing client, ***LogParser***, watches
|
|
log files and uses regular expressions to determine when particular
|
|
events have occurred. Because of the way regular expressions are mapped
|
|
in memory, scanning a single log for many different text patterns can
|
|
become memory intensive. Instead, we designed ***LogParser*** to
|
|
distribute monitoring overhead. Multiple instances of ***LogParser***
|
|
can run on separate feeds around the network, each instance searching
|
|
for only a few textual patterns in the local system logs. This allows
|
|
the system administrator to take advantage of the distributed computing
|
|
power of his network, rather than waste what is often an abundance of
|
|
idle resources in the hands of naive users. Peep aims to provide
|
|
administrators with several means of implementing monitoring.
|
|
Administrators still have the option of directing all log entries to a
|
|
single machine should they so desire, at the cost of increased network
|
|
bandwidth. Furthermore, the distributed method can be combined with the
|
|
single-machine method with no effort on the administrator's part.
|
|
|
|
Expanding the capabilities of Peep to fit your own needs is simple. Perl
|
|
libraries handle all the low-level details, so writing scripts for
|
|
event, state, and heartbeat-driven feeds can be quick and painless.
|
|
***LogParser*** can also be easily configured to scan a log for new
|
|
events via additional regular expressions.
|
|
|
|
# The Peep Protocol
|
|
|
|
Peep was designed to allow centralized management of its distributed
|
|
architecture. The Peep protocol uses auto-discovery to dynamically bind
|
|
clients and servers together upon startup. Peep configuration also uses
|
|
a class mechanism to define groups of clients that should all report
|
|
data to the same servers.
|
|
|
|
Peep was originally designed to use TCP for communication between
|
|
clients and servers but communication over UDP proved much more
|
|
efficient and effective. The main strength of TCP is its reliability.
|
|
However, this reliability comes at the cost of greater bandwidth usage.
|
|
Extra packets must be sent to ensure that transmissions were received
|
|
correctly and in the proper order. Peep does not require packets to be
|
|
ordered in any way - nor for packet transmissions to be reliable - since
|
|
the representation of the state of the network is an approximation
|
|
rather than a precise depiction. In any case, the human ear has no way
|
|
of distinguishing the exact order of events when events rapidly arrive
|
|
at the Peep server; indeed, the resulting sounds seem simultaneous.
|
|
|
|
The statelessness of UDP provided another benefit: clients and servers
|
|
can be stopped and restarted without affecting one another. We wanted
|
|
users to be able to write their own clients with minimal hassle.
|
|
Avoiding connection management keeps clients simple and allows one to
|
|
readily write Peep clients without making use of the included Perl
|
|
libraries.
|
|
|
|
One drawback to using UDP is that clients have difficulty determining
|
|
when servers crash. If this problem is not addressed, a client will
|
|
continue to provide data to a non-existent server forever. Peep deals
|
|
with this problem by combining a leasing mechanism with auto-discovery.
|
|
This combination provides safe, dynamic, real-time bindings between
|
|
clients and servers.
|
|
|
|
|
|
**Figure 2**: A server initialization.
|
|
|
|
**Figure 3**: A client initialization.
|
|
|
|
|
|
Peep's auto-discovery mechanism uses a domain-class concept to maintain
|
|
bindings between clients and their respective servers. When a server
|
|
initializes, it broadcasts its existence to the subnets associated with
|
|
its classes and announces the classes of which it is a part. The clients
|
|
that are members of those classes register themselves with the server
|
|
and begin sending it packets. Conversely, should a client start up and
|
|
broadcast its existence, the servers associated with its class will tell
|
|
it to begin sending. A broadcast only occurs once during the
|
|
initialization of each client or server, after which a list of hosts is
|
|
maintained on both sides and communications are direct. Both clients and
|
|
servers can belong to multiple classes at the same time and clients can
|
|
communicate with many servers concurrently.
|
|
|
|
Leasing is used to ensure that clients do not waste network bandwidth
|
|
and system resources sending packets to servers that are no longer
|
|
listening. The server sends a lease time to the client during
|
|
auto-discovery. Just before the lease expires, the server tells the
|
|
client to renew the lease. The client responds by telling the server
|
|
that it is still alive and still needs to know about lease information.
|
|
If the client has not heard from a server after the lease time has
|
|
expired, it will no longer send packets to that server. Similarly, if a
|
|
server does not receive lease acknowledgement from a client, it will no
|
|
longer attempt to renew its lease with that client.
|
|
|
|
The auto-discovery and lease mechanisms greatly ease the burden on the
|
|
system administrator. The system administrator can then use a file
|
|
distribution mechanism, like CFEngine, to add client and server daemons
|
|
to a machine's background processes. Clients will sleep until a server
|
|
becomes available, and will send packets only while that server stays
|
|
available.
|
|
|
|
Alternatively, system administrators may decide to dedicate a machine to
|
|
run Peep software and want all clients to execute on a single machine.
|
|
In this situation, broadcasting becomes totally unnecessary and
|
|
inefficient. Instead, the user can disable the auto-discovery mechanism.
|
|
Clients will then become dumb clients, continually processing and
|
|
sending event information to a server throughout the course of their
|
|
lifetimes. Peep also provides the user the choice of mixing and
|
|
matching, applying distributed and centralized configurations where they
|
|
make sense.
|
|
|
|
In terms of robustness, the Peep protocol has version identification,
|
|
room for future expansion, and type identification. Upgrades should
|
|
allow older clients to work with newer servers and vice versa.
|
|
Communications are done using one-byte quantities to represent
|
|
attributes, and strings for anything more complex. This allows us to
|
|
avoid any external data representation issues, making the protocol more
|
|
portable.
|
|
|
|
Details of this protocol are hidden inside a Perl client interface
|
|
library provided with Peep. The Peep library demands little expertise.
|
|
To create a client with all of the library's benefits, programmers need
|
|
only initialize the library with their application name and tell the
|
|
library what information to send. Initializing the library parses the
|
|
Peep master configuration file, so programmers need not do it
|
|
themselves. This allows client design to be as simple or as complicated
|
|
as the user desires. We hope that the simplicity of writing clients with
|
|
the Perl library will encourage users to write their own client
|
|
applications and share their code with others.
|
|
|
|
# Configuring the Peep System
|
|
|
|
How one configures Peep is very much dependent on whether you choose to
|
|
use single or multiple nodes. The generalized Peep installation is a
|
|
four-step process: downloading the source and a sound package, compiling
|
|
the server, editing the configuration file, and deploying clients.
|
|
|
|
The Peep server package uses the gnu autoconf package to make
|
|
configuration and compilation easy. Support for tcp\_wrappers \[11\] can
|
|
be added as an option. Peep comes with two generic sound modules. One
|
|
handles generic /dev/audio support while the other takes advantage of
|
|
ALSA \[1\] on Linux systems. The ***configure*** package will default to
|
|
ALSA drivers over generic support, if present. Special support for the
|
|
Sun audio jack is also provided.
|
|
|
|
After compilation, the next step is to tell Peep which sounds to
|
|
associate with which events, the classes to which your clients and
|
|
servers belong, and your client configurations. A simple Peep
|
|
configuration file is shown in Figure 4.
|
|
|
|
class myclass
|
|
broadcast 130.64.23.255:2000
|
|
server swami:2001
|
|
end myclass
|
|
client LogParser
|
|
class myclass
|
|
port 2000
|
|
config
|
|
#Name|OptLetter|Location|Priority|RegX
|
|
out-mail 0 1 "sendmail.*:.*from"
|
|
inc-mail I 255 0 "sendmail.*:.*to"
|
|
end config
|
|
end client LogParser
|
|
events
|
|
#Event Type|Path|# sounds to load
|
|
out-mail /path/sounds/peep1a.* 1
|
|
inc-mail /path/sounds/peep2a.* 1
|
|
end events
|
|
states
|
|
#Event Type|Path|# sounds| Fade time
|
|
loadavg /path/sounds/water.* 5 0.3
|
|
end states
|
|
|
|
|
|
**Figure 4**: An example peep.conf.
|
|
|
|
Class definitions consist of two lines: one specifying broadcast zones
|
|
and another specifying which servers are part of that class. Several
|
|
broadcast zones and servers can be specified. Clients and servers can be
|
|
part of several classes and will broadcast all the classes to which they
|
|
belong during initialization. Putting multiple servers in a class (or
|
|
making a client a member of multiple classes) is an easy way to have a
|
|
single client dump data to multiple servers.
|
|
|
|
The \`events' and \`states' sections tell Peep servers to associate a
|
|
name with a group of sounds. Filename descriptions in the Peep
|
|
configuration file have a trailing asterisk extension followed by the
|
|
number of sounds to load. Peep expands each asterisk into a two-digit
|
|
number and loads, in ascending order, the number of sounds specified.
|
|
All of the sound files loaded for a single entry then correspond to a
|
|
single event. Every time that event occurs, the server will randomly
|
|
play one of the associated sounds. This randomness makes the sound
|
|
ambiance more natural. Heartbeats are created from streams of normal
|
|
events from a client at suitable intervals. For state sounds, the server
|
|
randomly strings together sound segments to create a non-repeating,
|
|
random-sounding background ambiance. To keep transitions between sound
|
|
segments sounding natural, the user can specify a linear fade time
|
|
between segments.
|
|
|
|
The final step is to configure and deploy some of the clients provided
|
|
with Peep. Two of those are discussed here: ***Peck*** and
|
|
***LogParser***.
|
|
|
|
#### `Peck`
|
|
|
|
***Peck*** is a command-line utility provided with Peep. It allows the
|
|
user to tell a server to play (and how to play) a given sound.
|
|
***Peck*** is an example of a dumb client and bypasses the
|
|
auto-discovery and leasing mechanisms. Event and state attributes are
|
|
specified on the command-line and delivered directly to the server. Some
|
|
command-line options apply to event sounds and others to background
|
|
sounds, but the user need only remember a small number of options to get
|
|
the Peep server to play some interesting things. ***Peck*** can be
|
|
called with appropriate arguments from a shell script if a user does not
|
|
wish to use a client library. Ideally, one should only utilize
|
|
***Peck*** to talk to servers on the same physical machine, or to report
|
|
very infrequent events since ***Peck***'s inability to use
|
|
auto-discovery and leasing capabilities means that calling applications
|
|
will have no knowledge of the state of the receiving server. ***Peck***
|
|
is handy for a variety of simple tasks, including debugging
|
|
installations, testing how things sound together, experimenting with
|
|
Peep's capabilities, and interfacing Peep with other monitoring systems
|
|
(such as an existing Swatch or mon installation).
|
|
|
|
#### `LogParser`
|
|
|
|
A simple log analyzer, similar to Swatch, is also provided with Peep.
|
|
***LogParser*** takes advantage of Peep's auto-discovery and leasing
|
|
mechanisms. It is also an efficient distributed tool. ***LogParser***
|
|
reads its entire configuration but only searches for and remembers
|
|
textual patterns specified on the command-line. It was designed to have
|
|
multiple instances run on several different machines, each scanning for
|
|
different sets of textual patterns on each client machine.
|
|
|
|
***LogParser*** is flexible, easy to configure, and provides a simple
|
|
way to access Peep's capabilities for representing events and states. It
|
|
analyzes log messages as they are added to the log file and scans them
|
|
for regular expressions. ***LogParser*** uses simple configuration
|
|
syntax to generate command-line options and determine which sounds to
|
|
associate with which particular events. Several options follow:
|
|
|
|
- The **priority of the event ensures that no matter how many network
|
|
events hit the Peep server, the most important ones will be played
|
|
first and foremost.**
|
|
- The **stereo location of the event, aside from pleasing the true
|
|
audiophile, helps the user distinguish and even locate an event.
|
|
Sonic locations can even be assigned to correspond to the actual
|
|
locations of machines on the network. Future versions of Peep might
|
|
include a visual sound location map to exploit this.**
|
|
- A **regular expression that tells ***LogParser*** how to find the
|
|
event in a log file. Users with experience with Awk/Perl pattern
|
|
matching will appreciate this feature while others may find writing
|
|
these difficult. We feel this is the easiest way to extend the
|
|
capabilities of Peep without doing any sort of programming.**
|
|
|
|
Directives in the ***LogParser*** configuration can be enabled or
|
|
disabled via command-line options. Each line of the ***LogParser***
|
|
configuration corresponds to a user-specified single-letter option. In
|
|
Figure 4, incoming and outgoing mail are mapped to command-line options
|
|
\`\`I'' and \`\`O'', respectively. Thus, an invocation of
|
|
***LogParser*** searching for incoming mail might look as follows:
|
|
|
|
LogParser -events=I
|
|
-logfile=/var/log/messages
|
|
|
|
Should the user forget the options, a help option will conveniently
|
|
generate a list of user-configured options.
|
|
|
|
A single instance of ***LogParser*** can scan numerous logs
|
|
simultaneously. It can send event streams to multiple servers
|
|
automatically via the auto-discovery and domain-class mechanisms. These
|
|
features provide the user with a myriad of options for structuring the
|
|
architecture of Peep within a network.
|
|
|
|
# Peep Performance under Pressure
|
|
|
|
To deal with copious amounts of incoming network data, Peep has a
|
|
queuing and windowing system that handles large numbers of simultaneous
|
|
events. This ensures that events are played in the order of receipt and
|
|
in accordance with their particular priority. Peep will also discard
|
|
events from its queue if too much time elapses between receipt and
|
|
playtime, in order to keep events relevant.
|
|
|
|
Peep plays sounds by mixing sources in software. Since having large
|
|
numbers of simultaneous voices can become computationally expensive, the
|
|
user can tweak Peep's performance by changing the number of voices used
|
|
when mixing sound. Less mixing voices tend to mean that the Peep's
|
|
queuing and windowing system gets more usage, but the two always strike
|
|
a balance to keep events accurately positioned in terms of time of
|
|
occurrence.
|
|
|
|
It is difficult to send events to a Peep server fast enough to fill a
|
|
queue on a Pentium II 400 and during testing, this required the use of
|
|
an infinite loop. If the Peep server does manage to become overloaded,
|
|
it only falls behind time-wise, adding a delay between the real-time
|
|
event and the playing of its counterpart. Peep will preserve the general
|
|
order and users will still be able to diagnose problems based upon the
|
|
relative frequency of events. The delay experienced only applies to
|
|
events and heartbeats; state changes occur instantaneously. In a worst
|
|
case scenario, should the queue manage to fill up while new events are
|
|
still arriving, Peep will begin discarding the oldest events from the
|
|
queue, attempting to give the best approximation of network activity.
|
|
|
|
# A Brief Overview of Implementation
|
|
|
|
The inner-workings of a Peep server are based upon the interactions
|
|
between three execution threads as shown in Figure 5: the listener, the
|
|
engine, and the mixer. The listener handles all communications with the
|
|
client, discovering clients via auto-discovery and keeping track of
|
|
client leases. Upon receipt of event or state data, the listener thread
|
|
places the information into a queue to be processed by the engine. The
|
|
engine works closely in conjunction with the mixer to keep track of the
|
|
priority of incoming and currently playing sounds. The engine also tries
|
|
to find the best available mixing channel on which to play the incoming
|
|
events and informs the mixer of the necessary parameters to properly
|
|
represent the information. Should a suitable mixing channel not be
|
|
found, the engine will place the events into a priority queue, ensuring
|
|
that the mixer will play the most important events as soon as mixing
|
|
channels free up. The mixer performs the processing necessary to produce
|
|
Peep's output. This process involves scaling each sound's volume, as
|
|
well as fading between state sounds. The mixer must also check the
|
|
engine's event queue and ensure that queued, older events have priority
|
|
as soon as mixing channels free up.
|
|
|
|
# Critique
|
|
|
|
From our perspective, the design of Peep is very robust and portable. We
|
|
decided, however, that support for generic audio hardware was more
|
|
important than efficiency of memory and processor usage on the server
|
|
side. Peep utilizes Linux ALSA and OSS drivers, as well as the Solaris
|
|
/dev/audio interface, to avoid device incompatibilities. This is done at
|
|
the expense of ignoring commonly available device-dependent
|
|
hardware-based mixing in favor of mixing in software. Software mixing
|
|
did afford us one advantage that hardware cannot guarantee: users will
|
|
always get the benefit of sound processing incorporated into Peep
|
|
regardless of the hardware. Future plans do include support for
|
|
hardware-based mixing on a selected number of audio cards.
|
|
|
|
An invisible limitation of Peep is that creating accurate natural venues
|
|
of consonant sounds is both an art and very labor-intensive. Due to
|
|
copyright limitations on existing natural sound collections, Prof. Couch
|
|
has spent many hours with a Telinga parabolic nature microphone and Sony
|
|
DAT or digital minidisc recorder in search of the perfect bird. Sounds
|
|
we collected required significant post-processing, including high and
|
|
low-pass filtering and noise reduction, before they were free of enough
|
|
normal background noises to serve as event sounds. Collecting state
|
|
sounds proved even more difficult, with the sound of wind being the most
|
|
difficult. The challenge was to collect \`desirable noise' without
|
|
impurities such as car horns and airplane engines.
|
|
|
|
In spite of the excellent guidance on the recording of natural sounds
|
|
that we obtained from the Cornell Ornithology website \[13\], the Stokes
|
|
Field Guide to Bird Songs \[14, 15\], and the British Library National
|
|
Sound Archive \[12\] we are not ornithologists and apologize in advance
|
|
for any gross mislabeling of sounds included with Peep\! Nonetheless, we
|
|
have made significant progress in providing a Wetlands venue, and are
|
|
planning others in the future.
|
|
|
|
|
|
**Figure 5**: The Peep server's internal structure.
|
|
|
|
Configuring a Peep theme pleasingly can be non-trivial, especially when
|
|
choosing which sounds should be associated with which events. The
|
|
process of choosing sounds can often be a very lengthy. Since sounds
|
|
chosen vary according to personal taste and the situation they are
|
|
attempting to describe, we hope to provide several different preset
|
|
configurations for our users after the tool has had more exposure.
|
|
|
|
Peep is relatively young and prior to this publication has received very
|
|
little public usage. We hope we have anticipated and met the needs of a
|
|
wide range of network implementations. However, only public usage and
|
|
time will tell.
|
|
|
|
# Future Work
|
|
|
|
We want to see several other capabilities added to Peep servers to
|
|
better represent network events. One idea is \`log dithering'. Due to
|
|
block buffering, many log files are updated in erratic bursts so that
|
|
several events are written to the log file and reported by
|
|
***LogParser*** as simultaneous. A dither time would space out how the
|
|
events are played so they have a truer representation.
|
|
|
|
We also want to represent state sounds in a way that better models the
|
|
way the human ear works. Since the ear hears amplitudes on an
|
|
exponential scale (in dB), we want to scale state measurements
|
|
exponentially so that they better approximate what the human ear
|
|
considers truly loud. This still may not satisfy our vision of having a
|
|
storm break loose when a machine is overloaded.
|
|
|
|
We may also allow sounds to change in nature with volume. A small stream
|
|
might become a river rapid when a state measurement, such as load
|
|
average, increases. State sounds might be represented by three or four
|
|
different collections of sounds to achieve a \`thunderous' effect. A
|
|
final item on the server wish-list is pitch bending: the ability to play
|
|
sounds at different frequencies. Using this capability we could generate
|
|
birdcalls at different pitches and then combine them together to create
|
|
the effect of a chorus of distinct birds from a single sample.
|
|
|
|
We would also like to add a GUI to ease the process of configuring
|
|
sounds for Peep. Since we plan on having several different sound
|
|
classifications, a sound browser would be a welcome addition. The
|
|
interface would let the user play several sounds simultaneously so they
|
|
could get a feel for how things would sound in various situations. This
|
|
will most likely be the next major addition to the Peep software
|
|
package.
|
|
|
|
Lastly, we hope a few brave users will contribute homegrown scripts and
|
|
configurations to the project so that we can establish an archive and
|
|
ease the process of making a new installation.
|
|
|
|
# Conclusions
|
|
|
|
This work began two years ago by trying to define what constitutes
|
|
\`normal' behavior of a network and how to take action to rectify
|
|
\`abnormal' behavior. This proved infeasible because normalcy depends as
|
|
much upon policy decisions as upon many pre-existing conditions. These
|
|
conditions exhibit complexities and intricacies that are difficult to
|
|
depict via traditional methods.
|
|
|
|
Our sound ecology depicts normalcy in a new way. Things are normal when
|
|
Peep \`\`sounds like it did yesterday,'' regardless of the intricacy of
|
|
the depiction. Our innate human abilities to detect these differences
|
|
are more acute than one may realize. When things sound different, we may
|
|
not know why, but we can tell that *something* has changed.
|
|
|
|
Traditional tools look for specific problems while Peep only tells the
|
|
listener about potential problems. In that respect, Peep will outlast
|
|
traditional problem-detection tools because it portrays the general
|
|
problem and no more. And unlike other tools, Peep is non-intrusive. One
|
|
doesn't need to pay much attention to Peep in order to benefit. We don't
|
|
want you to. We just want you to sit back, and listen.
|
|
|
|
# Availability
|
|
|
|
The current revision of Peep is 0.3.0alpha and is is currently freely
|
|
available from <http://www.eecs.tufts.edu/peep/>. A demo of Peep's
|
|
capabilities will also be provided on the website in .wav format so
|
|
users can know what they're getting into before they install it.
|
|
|
|
# Acknowledgements
|
|
|
|
Thanks to USENIX for funding this project and making it possible.
|
|
Additional thanks goes to Andy Davidoff for contributing many great
|
|
design ideas throughout the course of Peep's development and for being
|
|
one of the first to embrace Peep software.
|
|
|
|
# Biography
|
|
|
|
Michael Gilfix was born in Winnipeg, Canada and presently resides in
|
|
Montreal, Canada where he attended high school at Lower Canada College.
|
|
He is currently a junior at Tufts University, where he is completing his
|
|
undergraduate degree in electrical engineering and his masters in
|
|
computer science. His interests include guitars, music, and computers in
|
|
all ways, shapes, and forms. While completing his degrees, he is
|
|
currently practicing the art of system administration in Tufts'
|
|
Electrical Engineering and Computer Science department. He will be
|
|
graduating in 2003. He can be reached via electronic mail as
|
|
<mgilfix@eecs.tufts.edu>. Reach him telephonically at +1 617-627-2804.
|
|
|
|
Alva L. Couch was born in Winston-Salem, North Carolina where he
|
|
attended the North Carolina School of the Arts as a high school major in
|
|
bassoon and contrabassoon performance. He received an S.B. in
|
|
Architecture from M.I.T. in 1978, after which he worked for four years
|
|
as a systems analyst and administrator at Harvard Medical School.
|
|
Returning to school, he received an M.S. in Mathematics from Tufts in
|
|
1987, and a Ph.D. in Mathematics from Tufts in 1988. He became a member
|
|
of the faculty of Tufts Department of Computer Science in the fall of
|
|
1988, and is currently an Associate Professor of Electrical Engineering
|
|
and Computer Science at Tufts. He can be reached by surface mail at the
|
|
Department of Electrical Engineering and Computer Science, 161 College
|
|
Avenue, Tufts University, Medford, MA 02155. He can be reached via
|
|
electronic mail as <couch@eecs.tufts.edu>. His work phone is +1
|
|
617-627-3674.
|
|
|
|
# References
|
|
|
|
\[1\] Advanced Linux Sound Architecture,
|
|
<http://www.alsa-project.org>.
|
|
\[2\] G. Kramer, Ed, *Auditory Display: Sonification, Audification, and
|
|
Auditory Interfaces*, Addison-Wesley, Inc. 1994.
|
|
\[3\] J. Francioni and J. A. Jackson, \`\`Breaking the Silence:
|
|
Auralization of Parallel Program Behavior,'' *Journal of Parallel and
|
|
Distributed Computing*, June 1993.
|
|
\[4\] J. Trocki, \`\`Mon, the Server Monitoring Daemon,''
|
|
<http://www.kernel.org/software/mon>.
|
|
\[5\] M. Brown, \`\`An Introduction to Zeus: Audiovisualization of Some
|
|
Elementary Sorting Algorithms,'' *CHI '92 proceedings*, Addison-Wesley,
|
|
Inc. 1992.
|
|
\[6\] M. Burgess, \`\`A Site Configuration Engine,'' *Computing
|
|
Systems*, 1995.
|
|
\[7\] M. Burgess, \`\`A Distributed Resource Administration Using
|
|
Cfengine,'' *Software: Practice and Experience*, 1997.
|
|
\[8\] M. Burgess, \`\`Computer Immunology,'' *Proceedings LISA XII*,
|
|
Usenix Assoc., 1998.
|
|
\[9\] M. Cooper, \`\`Overhauling Rdist for the '90's,'' *Proceedings
|
|
LISA VI*, Usenix Assoc., 1992.
|
|
\[10\] S. Hansen and T. Atkins, \`\`Centralized System Monitoring With
|
|
Swatch,'' *Proceedings LISA VII*, Usenix Assoc., 1993.
|
|
\[11\] W. Venema, \`\`TCP WRAPPER, network monitoring, access control,
|
|
and booby traps,'' *UNIX Security Symposium III*, September 1992.
|
|
\[12\] \`\`The British Library National Sound Archive,''
|
|
<http://www.bl.uk/collections/sound-archive>, The British Library,
|
|
2000.
|
|
\[13\] \`\`The Library of Natural Sounds,''
|
|
<http://birds.cornell.edu/lns/>, Cornell Lab of Ornithology, 2000.
|
|
\[14\] D. Stokes, L. Stokes, and L. Elliot, *Stokes Field Guide to Bird
|
|
Songs: Eastern Region* (three audio CD's), Warner Books, Inc., 1997.
|
|
\[15\] Peterson Field Guides, *Eastern/Central Bird Songs* (three audio
|
|
CD's), Houghton-Mifflin, Inc., 1999.
|