IBM Research
 

Traffic Lights

Try It Out

  1. Setup the Plugin
    • Start WBI. Setup your web browser to use WBI as a proxy.
    • Register the TrafficLights plugin. At the WBI console, type (on one line)
         register
            com/ibm/wbi/examples/traffic/traffic.reg
    • Check to see whether the plugin is registered and enabled. Go to the WBI Setup page. The TrafficLights plugin should be listed in the table with a checkmark next to its name. If the plugin is not listed, try registering it again. If the checkmark is not there, click on the box to the left of the plugin name.
    • Open another browser window. Use that window to try out the plugin, and use this window to display the documentation. (To open another window using Microsoft Internet Explorer, go to File -> New -> Window. To open a window using Netscape Navigator, go to File -> New -> Navigator Window.)
  2. Visit a Web Page
    • Access the WBI Homepage. Notice the small images that appear on both sides of each link. These images indicate the speed of the link (ie, how fast your browser will receive the information once you have clicked on the link). The color of the images indicate the speed of the link. The green images indicate the fastest links, yellow images indicate medium-speed links, and red images indicate slow links.
    • Access some other web pages. Try clicking on links with different images, and see if the change in response time is noticeable.
  3. Having Trouble?


What It Does

The TrafficLights plugin helps users browse the web more efficiently by giving them information about the speed of links. This information is represented as small red (slow), yellow (medium), and green (fast) annotations around links that indicate the speed of the connection to the server on the other end of the link.


How It Works

Architecture

The TrafficLights plugin edits retrieved web pages (by adding link speed annotations) before the web pages are shown to the user. The speed of a particular link is determined by requesting the root document from the requested server. To speed up this process, a database holds recent connection times for some links.

MEG Model

The following diagram shows how the TrafficLights plugin processes a web page request using two types of MEGs: generators ("G") and document editors ("DE"). The TrafficLights plugin uses generators to retrieve the annotation images and the web pages themselves, but the document editor is by far the most important MEG in the TrafficLights plugin.

WBI processing path

When the user clicks on a link to retrieve a web page, a request is created and sent to WBI. The page is then retrieved from the server using WBI's default generator. Before the user sees the page, a document editor edits it by adding speed annotations to the links.

Basically, there is an editor that modifies the markup of the page to add these annotations, and a generator that generates the images for the annotations. To make this all work, the plugin keeps a small database that contains (for each link) the time it takes to get a HEAD response for the root document of the server. This HEAD request times out after a bit if no response has come.

Implementation Details

  • Determining the speed of the connection: The basic plan of the TrafficLights plugin is to edit retrieved pages so that the links are annotated with appropriate traffic light images. In principle, this is a straightforward application of the LinkAnnotationEditor, which can be used to change the markup around anchor tags embedded in web pages. The main complication is that the editor does not always know how fast the conection to the server is when it marks up the page. One obvious but inappropriate approach would be to hold up page editing while the response time is determined for each server. This is a bad choice because introducing any delays into web transactions will almost certainly aggravate users.

    We have chosen to annotate the links on the page by sticking what are essentially promises for images into the markup. Rather than determining on the fly whether red, green, or yellow images ought to be inserted, the TrafficLightsEditor (1) starts the process of determining the response times for each server by launching a thread that fetch the root document from the server and eventually deposits the response time in a database; and (2) adds image tags whose src URLs encode the server and point to a special WBI generator that reads from the database of response times.

  • Modelling response times: Overall, we model response times as an exponential distribution and cut off the fast, medium, and slow values at specific points along this curve. The distibution adapts to the conection speeds that are actually observed by maintaining a little running history of response times. An Database is used as persistent storage for distribution of roundtrip times. This allows the speed indicators to adapt to the user's particular connection over time.

  • Some key WBI classes that were used:

    com.ibm.wbi.protocol.http
    HttpRequest used by ServerListEntry
    FetchUrl used by ServerListEntry
    HttpEditor extended by TrafficLightsEditorDispatcher
    HttpGenerator extended by TrafficLightGenerator
    HttpPlugin extended by TrafficLights
    DocumentInfo used by TrafficLightGenerator
    com.ibm.wbi.protocol.http.beans
    LinkAnnotationEditor extended by TrafficLightsEditor
    ResourceGenerator used by TrafficLightGenerator (to get speed images off local machine)
    com.ibm.wbi
    Generator used by ServerListEntry
    RequestEvent used by TrafficLightGenerator and TrafficLightsEditorDispatcher
    RequestRejectedException used by TrafficLightGenerator and TrafficLightsEditorDispatcher
    com.ibm.wbi.persistent
    Section used by the TrafficLights plugin itself


Known Problems

There are two basic kinds of problem we've seen with the TrafficLights plugin: the red, yellow, and green images mess up some nicely formatted pages, and the generator waits too long for a response from the server before timing out. Feel free to fix these (and send us your changes!).
  1. Though HTML is not really supoposed to be a language for precisely controlling the way a document is displayed, many web designers like to specify exactly how wide, how tall, and how lined up elements on their pages are. Hey, we do it too. The problem is that this makes it very difficult for a simple program to modify the markup automatically, and still maintain the proper look. The traffic lights do a pretty good job in most cases, but fail miserably in others. Play with it. Judge for yourself whether the benefit of the link speed annotations outweigh the messed up formattng.

  2. To determine how fast a connection to a server is, the TrafficLights plugin makes a HEAD request for the root document of the server and measures the response time. In making the connection to the remote machine, it passes FetchUrl a maximum time for the life of the socket that makes the connection, so that we have a chance of returning a reasonable period. Sometimes, however, the socket just doesn't timeout in this period. At this point, we're not sure why.


Source Files

bad.gif
Contains the image used for the slow traffic light.
good.gif
Contains the image used for the fast traffic light.
maybe.gif
Contains the image used for the medium-speed traffic light.
traffic.reg
Contains the code necessary to register the plugin.
TrafficLights.java
Contains the class definitions for TrafficLights, ExpDistribution, MeasureDelayWatchdog, ServerEntryLookup, ServerList, ServerListCleanup, ServerListEntry, ServerLookup, StoreLambdaPeriodic, TrafficLightGenerator, TrafficLightsEditor, and TrafficLightsEditorDispatcher.